cloudron cli 7.1.0 / instance 9.1.3 login

[timconsidine]

Would it not be easier to support use of a token for cloudron login ?

% cloudron login --token ffb1bc87d9ef8127f41aae7a7f950xxxxxxxxxxxxxxxxxxxxx --server my.example.uk
Cloudron Domain (e.g. my.example.com): my.example.uk
Opening browser for authentication...

Browser involvement seems bit retrograde to me ...

[james]

Hello @timconsidine

Thanks for the report.
We have to validate this with safari.

As an alternative method you can generate the ~/.cloudron.json manually with a pre-generated cloudron API token that has read-write access.

{
  "cloudrons": {
    "default": "my.cloudron.dev",
        "my.cloudron.dev": {
            "apiEndpoint": "my.cloudron.dev",
            "token": "$YOUR_TOKEN_GOES_HERE"
        },
  }
}

Or with a script using jq or yq:

jq -n '
{
  cloudrons: {
    default: env.CLOUDRON_DOMAIN,
    (env.CLOUDRON_DOMAIN): {
      apiEndpoint: env.CLOUDRON_DOMAIN,
      token: env.CLOUDRON_TOKEN
    }
  }
}' > ~/.cloudron.json

or

yq -n '
{
  "cloudrons": {
    "default": strenv(CLOUDRON_DOMAIN),
    (strenv(CLOUDRON_DOMAIN)): {
      "apiEndpoint": strenv(CLOUDRON_DOMAIN),
      "token": strenv(CLOUDRON_TOKEN)
    }
  }
}' > ~/.cloudron.json

[james]

Hello @timconsidine

@timconsidine said:

Browser involvement seems bit retrograde to me ...

Yes and No.
We had to make this switch to also support passkeys and other future webauthn validations.
Other tools like npm cli or docker cli have also made the switch to the browser style auth flow.

[girish]

@timconsidine I published a 7.1.1 which explicitly listens on IPv4. Can you check if that fixes anything? It's probably a Mac issue and not safari specifc. Do you have any more details on the error?

[timconsidine]

Thanks -@James and @girish
I held off manual creation of ~/.cloudron.json so as to test 7.1.1

% sudo npm install -g cloudron
Password:

changed 60 packages in 3s

17 packages are looking for funding
  run `npm fund` for details
% cloudron -V
7.1.1
% rm ~/.cloudron.json 
% cloudron login
Cloudron Domain (e.g. my.example.com): my.example.uk
Press ENTER to authenticate using the browser...

Browser (Safari) says :

Safari Can’t Open the Page

Safari can’t open the page “http://localhost:1312/callback?code=TG_GsgNBsyfaY66pc4HsIj7135uFiuY7xvNM896Qwwl&state=24225191912c03d1feae234a7335894e&iss=https%3A%2F%2Fmy.example.uk%2Fopenid”. The error is: “Navigation failed because the request was for an HTTP URL with HTTPS-Only enabled” (WebKitErrorDomain:305)

specifically : Navigation failed because the request was for an HTTP URL with HTTPS-Only enabled” (WebKitErrorDomain:305)

I don't see anything else in browser dev view console or network.

Laptop terminal times out with this :

file:///Users/username/.nvm/versions/node/v25.2.1/lib/node_modules/cloudron/src/helper.js:157
            reject(new Error('Login timed out after 2 minutes'));
                   ^

Error: Login timed out after 2 minutes
    at Timeout._onTimeout (file:///Users/username/.nvm/versions/node/v25.2.1/lib/node_modules/cloudron/src/helper.js:157:20)
    at listOnTimeout (node:internal/timers:605:17)
    at process.processTimers (node:internal/timers:541:7)

Node.js v25.2.1

[timconsidine]

@james said:

We had to make this switch to also support passkeys and other future webauthn validations.

cool
understood

[girish]

@timconsidine you might have to add localhost as an exception in safari for localhost - https://github.com/orgs/community/discussions/161229 . Could that be the problem? Do you do local development in safari? Wondering why it's not already in the whitelist.

[timconsidine]

Wow - thank you so much for taking the time to research like that
Weirdly I could not find how in Safari to do that (embarrassing)
So I threw teddy out of pram, closed safari, set Firefox as default, and it worked immediately after pressing ENTER
Thank you !
Not sure whether I will switch back.
I hate Chrome, as an experience but also in principle, don’t really like Firefox and am tired of “also-ran” alternatives.

Thanks again for taking the time to solve this

[girish]

@timconsidine I think probably a better way to implement this was so called Device Authorization Flow . That approach doesn't require callback to localhost. We are looking into implement the cli auth that way instead.

[girish]

Device Authorization Flow is implemented in 9.1.4 (will be released shortly). With this, it won't require cors/callback.