Enhancement: Improvement to new login workflow

[3zero2]

Version 1.6.0 introduces a new login procedure. This procedure does not work seamlessly on headless or strictly CLI operating systems.

Current Process:

1. The login process asks to open a browser and provides the link.
2. Link needs to be copied and pasted on a computer with a browser
3. Browser returns a 127.0.0.1 address which needs to be copied.
4. Subsequently a CURL command followed by the URL provided by the browser needs to be issued on the computer where the login is happening.

This process is not seamless and requires manual intervention. I understand that the legacy login is still available, however I would assume that eventually the legacy login will be removed.

Below I'm proposing an improved process which might be of benefit on headless, non-GUI systems; maybe under an internxt login-headless command.

Improved Process:

1. The login process asks to open a browser and provides the link. Link is structured so that the Internxt service realises that it's coming from a headless request.
2. Link copied and pasted on a computer with a browser
3. Browser returns a code rather than another URL address which needs to be copied.
4. Code is provided to the internxt login-headless command

[larryrider]

Hey @3zero2!
Thanks a lot for the detailed feedback and for taking the time to propose an improved headless workflow, we really appreciate it.

Regarding your concern: the new internxt login command already supports changing the callback URL, so you don't have to rely on 127.0.0.1.
You can specify the host where the CLI is running like this: internxt login --host=<IP_OF_YOUR_MACHINE>

By setting --host to the machine's actual IP, the browser callback will correctly reach the CLI even in headless or remote environments.

We implemented this new login method because it's the same authentication flow used across all our other apps, ensuring consistency and better long-term maintainability.

The workflow you're suggesting (where the browser returns a short code instead of a callback URL) is something we're already familiar with and definitely aligns with a "headless-first" login experience. We absolutely agree that it would make fully non-interactive logins smoother. That said, it requires additional support on our backend side. Once that infrastructure is ready, we do plan to introduce a flow like the one you described.

For now, because many environments still depend on it, we have no plans to remove the legacy login. It will remain available for cases where the interactive flow isn't practical.

Thanks again for the suggestion, it's valuable feedback, and it helps us shape where the CLI is heading.
If you have any other ideas or run into issues, feel free to share them!

[debben80]

Hello,

A flow that could be more practical for cli-headless, is creating tokens (with expiration date) on web interface.
Ideally restricting tokens to some directories and/or read/write access.
And use the username + token to connect on cli.