CLI - login 2fa auth as parameter
-
Currently the CLI only supports parameters for username and password.
It would be better if it also supported 2fa code, as in :
cloudron login -u username -p password -2fa 123456 my.domain.tld
username mandatory
password mandatory
2fa optional (not everyone uses it)
domain mandatoryThe CLI seems to have periodic updates, could this be added to the next one ?
-
Hello @timconsidine
Thanks for this feature request, I think this would be a good addition.
If one wants to use the cloudron-cli in an automated context, the-2fa
parameter would be useful.While writing this, I noticed that the https://docs.cloudron.io/packaging/cli/#login section is "missing" another way of authentication.
Why quoting "missing" like that? Well this is more, if you know it, you know it.
You can create a Cloudron API Token with read/write access in the Cloudron Dashboard in your user profile and use this token for authentication.
But there is no
--token
parameter?We should add this as well.
But, what is working right now:
Create the following file
~/.cloudron.json
and insert your config:{ "cloudrons": { "default": "my.cloudron.dev", "my.cloudron.dev": { "apiEndpoint": "my.cloudron.dev", "token": "$THE-API-TOKEN-YOU-JUST-GENERATED" } } }
and run:
cloudron login my.cloudron.dev
This will work and authenticate your user with this API token without 2fa.
-
Since I was writing about automation and using the cloudron-cli in this context.
You can generate this file with theyq
command line tool like this:export TOKEN="APITOKEN" yq -n -o=json '{"cloudrons": {"default": "my.cloudron.dev", "my.cloudron.dev": {"apiEndpoint": "my.cloudron.dev", "token": env(TOKEN)}}}' > ~/.cloudron.json
Edit the command to use your cloudron domain, or even further use
env()
to make this more flexible.export CLOUDRON_DEFAULT="my.cloudron.dev" # Replace with your default export CLOUDRON_API_ENDPOINT="my.cloudron.dev" # Replace with your api endpoint export CLOUDRON_TOKEN="APITOKEN" # Replace with your actual token
yq -n -o=json '{ "cloudrons": { "default": env(CLOUDRON_DEFAULT), (env(CLOUDRON_DEFAULT)): { "apiEndpoint": env(CLOUDRON_API_ENDPOINT), "token": env(CLOUDRON_TOKEN) } } }' > ~/.cloudron.json
-
@timconsidine can you explain the use case for -2fa a bit more? Is the use case for desktop? How do you generate OTPs? Is the ultimate intent to save some keystrokes (which is fine, but just want to understand for sure)?
@girish TBH primary motivation was that when building my CCAI custom app installer, I really struggled for a while with handling the prompt to submit 2fa after
cloudron login -u username -p password my.domain.tld
I thought that adding a
-2fa
parameter would save a lot of code and hassle, and make it more robust process.Eventually I got the existing process working so maybe it is not so important.
The user still needs to generate and supply the 2fa, so there is no security side-step, and I'm not seeking to generate one programmatically. Just take what user supplies but hopefully login in one command, rather than check for prompt etc.
Maybe a simple auth token from the Cloudron profile would also work better, but not tried it yet.
-
@james we already have --token (primarily meant for CI automation). It's not saved in the cloudron.json intentionally because long-lived tokens should ideally not get saved somewhere. With login, you get a temporary token that is stored in the cache file.
I think maybe your point is that we should use API tokens to login in general? I wouldn't mind removing username/password based login entirely. The current auth mechanism of CLI bypasses all the OIDC security mechanisms . CLI tools like npm already now require auth on browser. I think we will move to this in coming releases. Technically, the CLI was not built for end users, it was only for app development. Not sure how many people this impacts. https://www.npmjs.com/package/cloudron does say ~400 a week....