Handling of auth commands with valid token in TURSO_API_TOKEN env

[CodingDoug]

Assuming the user is already signed in with a token that works:

$ turso auth token
[EXISTING TOKEN]

$ export TURSO_API_TOKEN=[EXISTING TOKEN]

$ turso auth logout
Logged out.

$ turso db list
[DATABASE LIST OK]

At this point, we have a token in env, nothing in settings.json, and commands requiring auth are working OK.

However, the following sequence of commands don't make sense given this context:

$ turso auth logout
No user logged in.

Is that response accurate? I'm implicitly logged in by way of env token.

$ turso auth login
Visit this URL on this device to log in:
https://api.chiseledge.com?port=55346&redirect=true
Waiting for authentication...
✔  Success! Logged in as CodingDoug

$ grep -i token settings.json
  "token": "[NEW TOKEN]",

$ echo $TURSO_API_TOKEN
[EXISTING TOKEN]

At this point, there are two tokens in the system, env and settings.json. Auth login went ahead and did its thing without regard to env.

$ turso db list
[DATABASE LIST OK]

Which token was responsible for allowing this command to work? It's unclear.

$ turso auth logout
Logged out.

$ turso auth token
Error: no user logged in. Run turso auth login to log in and get a token

$ turso db list
[DATABASE LIST OK]

The fact that the command still works after logout could be confusing. The CLI is now back to using the first token, but we've received no acknowledgement about this.

Proposal:

• If there is a token in env, all auth commands should fail saying that auth commands aren't effective when a token is in env.
• If there is a token provided with -t, similar to above.

Even better, if the CLI can decode the token, for any command that requires a token:

• If the token can't be parsed at all, error out and say that.
• If the token is expired, say that, and suggest turso auth login to get a new one.

[athoscouto]

If there is a token in env, all auth commands should fail saying that auth commands aren't effective when a token is in env.

Do you see any problem with just giving a warning telling the user that there is an env var token?

[CodingDoug]

Do you see any problem with just giving a warning telling the user that there is an env var token?

By this, you mean the command still does its work, but with warning output first thing? For login that's seems unlikely to be effective since running the command immediately pops up a browser window, and you wouldn't see the warning until auth completes and the user returns to the CLI. And even then, they still might miss the warning, focusing instead of the success result. It might be better to simply fail ASAP and ask them reckon with the env var before doing anything else.

[haaawk]

I think what @athoscouto is suggesting and I think I agree with it is:

1. Allow auth login, auth logout to work normally with no warning
2. For any other command print a warning at the top saying that the token used to execute this command is the one taken from TURSO_API_TOKEN env variable (or from a flag if that's the case).

That should remove all confusion.

[CodingDoug]

@haaawk OK, that's starting to overlap a bit with the sibling issue #271, which is elaborating a bit on this suggestion.

[athoscouto]

My suggestion is actually the other way around. Allow auth commands normally, with a big warning saying that there is an env var set, which takes precedence over the token manipulated by the login command. Other commands work as they do now.

[CodingDoug]

Allow auth commands normally, with a big warning saying that there is an env var set, which takes precedence over the token manipulated by the login command.

I think the only way this works out for login is if the warning message comes after the success message for the reason I mentioned earlier.