Enable headless/remote use of the CLI without a local browser

[CodingDoug]

Currently the CLI requires use of a locally running browser to handle the auth flow. This doesn't work at all for users working on a remote shell. There should be a way to get a token on a local machine with a browser so they can forward it to the remote CLI.

Assuming the web flow already exists and ends with a page that ends with a token, we can add a CLI command such as turso db token --set [token] so the user can copy it into place.

The main downside here is that the CLI also stores the GH username in another field and uses that for various messages. If it is not possible to parse the token to extract the username, we might want to instead generate a different (JSON?) string that includes the username so that the copied blob can contain everything needed for the CLI to operate correctly. Either that, or we accept a default username for remote CLIs that is not confusing, or some other experience that does not print the username at all in this scenario.

[haaawk]

It is already possible to set the token either using env variable or a CLI flag. See https://github.com/chiselstrike/iku-turso-cli/pull/213.

Which messages that contain username do you have in mind @CodingDoug ? I grepped the codebase and the only two messages I found which contains username are:

       if isJwtTokenValid(settings.GetToken()) {
                username := settings.GetUsername()
                if len(username) > 0 {
                        fmt.Printf("Already signed in as %s. Use %s to log out of this account\n", username, turso.Emph("turso au
th logout"))
                } else {
                        fmt.Println("✔  Success! Existing JWT still valid")
                }
                return nil
        }

and

fmt.Printf("✔  Success! Logged in as %s\n", username)

The first one handless missing username alright and the second is printed from callback after auth so it won't happen on headless/remote instance.

[haaawk]

So just to be clear:

1. turso db login now prints the url one can enter to the browser and that browser will show the token
2. This token can be used in headless/remote environment either using TURSO_API_TOKEN env variable or --token/-t flag
3. I don't think in case of missing username any confusing message will be printed

[CodingDoug]

@glommer Were you able to use that URL to get a token in your headless environment? It sounded to me that you couldn't because of the redirect to localhost, which of course doesn't exist when the CLI is remote.

[glommer]

I didn't see the token in the browser at all. Mind you: because I had a text-based browser installed, it actually opened that. So I was on localhost (with a text browser). The auth flow worked fine, the final redirect to the cli's http server never happened.

[haaawk]

The token is on the page -> https://github.com/chiselstrike/iku-turso-api/blob/main/api/public/user.html#L15

I think @athoscouto did this work for WSL, no?

[CodingDoug]

So, what is the workflow that works today? It seems like you'd have to:

1. Log in with turso locally.
2. Get the token with turso auth token
3. Copy that into the remote shell, either setting env or using --token

The problem as I see it is that 1 might not be an agreeable option. Chromebooks (and other devices that don't support the turso CLI running locally) wouldn't work at all. And the auth web flow doesn't print the token directly at all - it just passes it back to the local CLI via redirect.

[haaawk]

This is an option but you can as well do:

1. turso auth login on remote/headless computer
2. Copy the url it prints
3. Put that url into browser somewhere
4. Copy token and use --token flag

[haaawk]

This isn't a CLI issue but a problem with the API server. Closing in favour of https://github.com/chiselstrike/iku-turso-api/issues/191