Save server specific login tokens in server config

[aceysmith]

Description of Changes

These changes only impact the spacetime CLI.

Currently, if a user is explicitly logging into a server using the spacetime login --server-issued-login <server name> or less directly by indicating N to the You are not logged in. Would you like to log in with spacetimedb.com? prompt, a JWT is created that is only valid for that specific server. Since the current cli.toml only supports a single spacetimedb-token at the root of the config, this quickly leads to collisions and attempts to spacetime publish or performance other actions with tokens that are invalid if you are using multiple servers.

This change will store a spacetimedb-token value in the associated server config section in the cli.toml file. Here are the impacts to specific commands:

spacetime login --server-issued-login <server name>

This command will store the generated JWT in the cli.toml section associated with that server. If a token is present already, it will give the existing You are already logged in. message, ignoring the spacetimedb-token value at the root config if present.

spacetime login show --server

A new flag has been introduced to this command to display the identity of the token stored for the provided server. If the server name is provided, the command will additionally display the name in the output. Example:

You are logged in to server "local" as c200a6e078b49844fefc3c060ac6d467eb1a122fc8533f7c65639fe34b048e8e

spacetime logout

This command will additionally delete all server spacetimedb-token values stored. This might be a bit harsh, but the intention of spacetime logout before was clearly remove all tokens and authentication, so this seemed most safe. Alternatively, we could only remove the root tokens and leave the server specific tokens intact and introduce a --server flag to log out of the specific server, but this seemed more consistent.

spacetime publish / spacetime sql / spacetime logs/ etc.

Any command that might have a path to force the user to log in to the server directly as a result of #2158 has the possibility of creating a JWT that will be stored as part of the provided (or default) server config if the user indicates they want to log in directly.

Unlike the above mentioned spacetime login show command, these will fall back to the root spacetimedb-token value. This is to handle backwards compatibility for users who have managed localhost JWTs already and would expect that functionality to persist, as well as to support centrally authoritative tokens like those generated by auth.spacetimedb.com or custom auth providers.

spacetime server edit

This command is not impacted by this change. If you have a spacetimedb-token value associated with the server, it will get carried along if present.

API and ABI breaking changes

None

Expected complexity level and risk

2

Testing

spacetime login --server-issued-login local
# verify a new local JWT is created and stored in the `local` server config within the `cli.toml`

spacetime login --server-issued-login local
# verify you receive the `You are already logged in.` message

spacetime login show -s local
# verify the `You are logged in to server "local" as ...` message is shown

spacetime logs -s local <module name>
# This should successfully display logs

spacetime logout
# verify ALL JWTs are removed from `cli.toml`

[CLAassistant]

All committers have signed the CLA.

[aceysmith]

I did see notes in the code about separating out tokens into its own credentials file or similar, but that seemed out of scope and a bit more complex. Hope folks find some value here :-) A nice side effect of this change is if you want to store/save different tokens for different servers, you can now do that while also allowing web login to create a root token that can be used for other servers.

I also understand possible workarounds of providing different --config-path to manage different logins, but having tried that a bit, it felt a lot more tedious.