Generate API key programmatically

[saikarthikp9]

Be able to generate an API key without logging into the Shlink instance and running the command 'shlink api-key:generate

[saikarthikp9]

One simple solution/workaround is to run the api-key generate command at the end of the docker-entrypoint.sh script. Since this has to be done only once assuming the database is persistent, we can check if keys are existing in DB by using the api-key:list call and (wc -l) and then decide to create a key or not. Many assumptions here and will not work in all scenarios. Just thought it might help someone.

[zanderson-aim]

Checking to see if this is still on the radar. Deploying this in Kubernetes and would be very helpful. Even better (for me) would be setting a/the API key using a ENV. Trying to deploy this stateless.

[soccerdude288]

I would also love the ability to set the API Key to a pre-generated value, be that over the CLI or with ENV.

My use case, is multiple devs with a local microk8s cluster, and not requiring everyone to have to generate their own API Key.

[onedr0p]

Chiming in to request the same thing, having a preset api-key you can define in ENV would be cake for automation of creating shlink instances.

[acelaya]

I have some concerns about the suggestions here, but to be honest, I don't see any better solution.

• Automatically run api.key:generate as part of the deocker entry point.

  It has the problem that you still need to manually access the container output in order to see what was the generated value.

  Considering it is not designed to be consumed by a machine, collecting that output might be cumbersome depending on your set-up.

  Also, it would not work for anyone not running the docker image.

• Provide a first key via env var.

  I like this one slightly better, as it can cover any of the supported ways to run Shlink, but it also has some problems.

  First of all, the API key should be created only once, meaning it should check if either there's no API keys at all, or only that API key does not exist, or maybe there should be a new way to categorize API keys so that there's only one of type "initial_api_key".

  This behavior is needed, but can be very unintuitive. People might expect the API key to be deleted if they stop providing the env var, or replaced if they change the value, etc.

  Because of this I'm skeptical about implementing anything at all.

[onedr0p]

This behavior is needed, but can be very unintuitive. People might expect the API key to be deleted if they stop providing the env var, or replaced if they change the value, etc.

As you kind of mentioned, maybe make the environment variable name reflect its purpose like: INITIAL_APIKEY that would get me to look at the docs to see why it's prefixed with initial.

[acelaya]

that would get me to look at the docs

You overestimate the average human being 😂

But yeah, that's probably the only possible approach.

[acelaya]

After giving this a thought, I realized that having to make a check to see if the initial API key exists and create it otherwise, would have a big impact for those using php-fpm, where Shlink is bootstrapped on every request.

Because of that I have decided to support the INITIAL_API_KEY only when using openswoole or RoadRunner (which is the case for the docker image), and add a new step in shlink-installer that allows to generate a first API key, as this is run only once and will cover the php-fpm use-case.

[acelaya]

This is now implemented and will be part of Shlink 3.3.0.

• Shlink will honor INITIAL_API_KEY when serving it with openswoole/RoadRunner/docker.
• The documentation has been updated (but not yet published) to explain the considerations when using this env var.
• The installer has been updated to automatically run api-key:generate at the end, as it's an interactive tool and it's expected that a human is in front of it. This will remove a step that previously had to be done manually.