hi @francisco-mata - thank you for submitting this issue.

i've reproduced the behavior on our latest version, 0.24.1. it's unclear to me whether this is the intended behavior, or a bug. i'm following up with engineering and will reach out when I learn more.

update: i've confirmed with product that this is a bug.

Thanks for the quick response @ericpaulsen. I'm glad to know its a bug and not the intended behaviour.

The issue is that /logout deletes the API token being used:

We should not delete the token being used if the token was created via the token create command.

What I will implement is /logout will fail with tokens. I will print a message to use coder token delete if the user tries to use /logout.

@Emyrk but the token should survive to an user logout, don't they? If you create a token, is because you want to log as user using the token instead of credentials. And this token will life till lifetime duration expire or user wants to delete the token. I dont see why it should failed if user logouts or the token will be delete if user logouts.

@Emyrk I suggest that instead, coder login --token should create a new session token with the usual session token semantics & expiry. We should not persist the token given on the command line as their session.

@spikecurtis would that not be a bit confusing?

This works because "token" is a global level flag.

So all commands allow the --token flag, which makes sense for one off commands. I don't think coder ls --token should create a new session.

I do see value in having a command to use a provided token. Would it not be confusing if coder login --token=<token> didn't use the provided token? I am guessing we would just use the token to make an api key rather than redirecting to the UI.

--

@francisco-mata

@Emyrk but the token should survive to an user logout, don't they?

When you hit the /logout route, the server deletes that session token. It does this because it is the other half of /login.

What you are trying to do I believe, is have the cli delete the credentials on the local disk. I think we make another command for that, or add some flag to do a client-side "logout".

So basically /logout is the other half of /login. It should undo what /login does. If the token comes from token create, then /logout doesn't make sense. I think it would be better to throw an error than to do something potentially unexpected. For your use case, another command or flag can be implemented with documented behavior.

So all commands allow the --token flag, which makes sense for one off commands. I don't think coder ls --token should create a new session.

I do see value in having a command to use a provided token. Would it not be confusing if coder login --token= didn't use the provided token? I am guessing we would just use the token to make an api key rather than redirecting to the UI.

Yeah, I think it makes sense for --token to use that token for the command being invoked. We shouldn't be storing that token for later use.

In the case of coder login --token, we still use the token, during that command, to authenticate against the API, but then as you say, we generate a new token, and only the new token is persisted, in the same way we would if you logged in via the UI. So, you used the token to "login", but once you are logged in, it's a different, session token that gets persisted. When you "logout" the persisted token is invalidated, but the token you used on coder login is still valid.

This gives us the following properties:

1. logout is the other half of login, and undoes it
2. --token uses the token for the command being executed, but does not persist the token

Sorry I got confused a bit, just to get a clear idea. If I create a token with the command coder token create --lifetime 24h, it will be deleted only 24 hours after creation or if I manually run coder token delete. For all the other cases token will persist and will be vaild to use, even tho my session is already logout.

So all commands allow the --token flag, which makes sense for one off commands. I don't think coder ls --token should create a new session.
I do see value in having a command to use a provided token. Would it not be confusing if coder login --token= didn't use the provided token? I am guessing we would just use the token to make an api key rather than redirecting to the UI.

Yeah, I think it makes sense for --token to use that token for the command being invoked. We shouldn't be storing that token for later use.

In the case of coder login --token, we still use the token, during that command, to authenticate against the API, but then as you say, we generate a new token, and only the new token is persisted, in the same way we would if you logged in via the UI. So, you used the token to "login", but once you are logged in, it's a different, session token that gets persisted. When you "logout" the persisted token is invalidated, but the token you used on coder login is still valid.

This gives us the following properties:

1. logout is the other half of login, and undoes it
2. --token uses the token for the command being executed, but does not persist the token

Ah I see. That does make sense.

If I create a token with the command coder token create --lifetime 24h, it will be deleted only 24 hours after creation or if I manually run coder token delete.

Yes

For all the other cases token will persist and will be vaild to use, even tho my session is already logout.

What do you mean "for all ther other cases"? @spikecurtis is suggesting doing coder login --token <token> and then doing coder logout will not delete <token>.