Handle auto-creation of API user along Super User

[Amphaal]

Would fix #2314

[knadh]

Thanks for the PR @Amphaal. API secrets are randomly generated, so it doesn't seem right to pass a manually constructed random looking secret into the DB from the CLI. Doesn't seem semantically right.

I do agree that it'd be good to have a way to generate a fully capable API user programmatically.

Would be good to know how other apps approach this. Have you seen examples?

[Amphaal]

No problem @knadh !

I agree with you, this is kind of an hack to allow "admin" permissions - like we would have pre v4 - which allows me to setup listmonk using automation.

What I am used to regarding token usage are:

• Pre-generated "admin" API token somewhere on the container triggered by ENV parameterization, that we need to extract via volume binding on a specific path
• Short-lived generation of tokens via a POST request (for example on /login/generateToken) that we would trigger using the classic Authorization auth method of existing admin user-password pair

Regarding current implementation, the first solution seems to fit. Let me know your thoughts about this !

[knadh]

Thanks @Amphaal. API tokens are auto-generated strings, so passing a manually constructed string seems off. It then allows for string patterns (including proper words) to be passed as tokens, which technically is fine, but semantically, incorrect.

I think a more semantic, but slightly clunky approach is to auto-generate a token (when LISTMONK_ADMIN_API_USER is set) and print it to stdout, which can then be captured and extracted. This is a standard practice as well (eg: openssl CLI).