Skip to content

gleam hex authenticate must be run twice to switch accounts. #4319

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hayleigh-dot-dev opened this issue Mar 9, 2025 · 5 comments · May be fixed by #4446 or #4447
Open

gleam hex authenticate must be run twice to switch accounts. #4319

hayleigh-dot-dev opened this issue Mar 9, 2025 · 5 comments · May be fixed by #4446 or #4447
Labels
discussion The approach has not yet been decided help wanted Contributions encouraged priority:medium

Comments

@hayleigh-dot-dev
Copy link
Member

If you hold multiple hex accounts, you might want to replace the local token gleam uses to interact with the hex api from time to time. This consistently fails when changing account details and must always be run a second time to succeed.

Steps to reproduce:

  • run gleam hex authenticate for the first time to generate a local token for hex account A
  • run gleam hex authenticate a second time, confirm that you would like to replace the local token, and provide different credentials for hex account B
  • observe the following error
% gleam hex authenticate

You already have a local Hex API token. Would you like to replace it
with a new one? [y/n]: y
https://hex.pm username: B
https://hex.pm password (will not be printed as you type): 

Please enter a new unique password. This will be used to locally
encrypt your Hex API key.

Local password (will not be printed as you type):
Encrypted Hex API key written to .../gleam/hex/hexpm/credentials
Deleting previous key `...` from Hex
error: Hex API failure

There was a problem when using the Hex API.

This was error from the Hex client library:

    an unexpected response was sent by Hex: 404 Not Found: {"message":"Page not found","status":404}
  • Run gleam hex authenticate a third time exactly the same as above
% gleam hex authenticate

You already have a local Hex API token. Would you like to replace it
with a new one? [y/n]: y
https://hex.pm username: B
https://hex.pm password (will not be printed as you type):

Please enter a new unique password. This will be used to locally
encrypt your Hex API key.

Local password (will not be printed as you type):
Encrypted Hex API key written to .../gleam/hex/hexpm/credentials
Deleting previous key `...` from Hex
  • Observe that the token has successfully been replaced.

You can continue to confirm the issue by attempting to authenticate with hex account A again and observe you must go through the command twice more.

@lpil
Copy link
Member

lpil commented Mar 10, 2025

Ah! Thank you.

The build tool assumes that the token is for the same account as the previous one, and then tries to use it to invalidate the old token.

We should not try to invalidate in that case, but what should we do instead?

@lpil lpil added help wanted Contributions encouraged good first issue Good for newcomers priority:medium discussion The approach has not yet been decided and removed good first issue Good for newcomers labels Mar 10, 2025
@scristobal
Copy link
Contributor

I would gladly work on this.

My proposal would be to add a new gleam hex deauthenticate command that removes and invalidates the local token.

Because of the name of the operation being "deauthenticate" there should be no confusion to which username/password we are referring to. (Which I think is the source of this particular issue).

In addition to this, if the token can not be invalidated, show a warning instead of an error.

Finally, if the user runs gleam hex authenticate but there is already a token, maybe just display a message to the user explaining the situation and why she should try again after run gleam hex deauthenticate.

In the long run I guess the best would be to support multiple accounts. @lpil Do you think this would be something of interest?

@lpil
Copy link
Member

lpil commented Mar 27, 2025

That command could be useful, but I think that's not quite the same thing as solving this problem. I think we need to start storing the name of the user and the name of the API key with the API key itself so we can tell if we are able to revoke it or not.

We'll need to decide what the behaviour should be for the authenticate command. Perhaps if the name doesn't match we could print a message telling the programmer to do it themselves and giving a link to the Hex page?

@scristobal
Copy link
Contributor

That command could be useful, but I think that's not quite the same thing as solving this problem. I think we need to start storing the name of the user and the name of the API key with the API key itself so we can tell if we are able to revoke it or not.

We'll need to decide what the behaviour should be for the authenticate command. Perhaps if the name doesn't match we could print a message telling the programmer to do it themselves and giving a link to the Hex page?

that makes sense, I will come with something more concrete in the form of a PR in the upcoming days. thanks for the hints!

@scristobal

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion The approach has not yet been decided help wanted Contributions encouraged priority:medium
Projects
None yet
3 participants