Conversation
Signed-off-by: Alex Hokanson <[email protected]>
Signed-off-by: Alex Hokanson <[email protected]>
|
PTAL @silvin-lubecki @rumpl |
|
@ingshtrom correct me if I'm wrong, but I think that this way all hub-tool commands will prompt for a 6-digit code if 2FA is enabled, right? It means the |
|
Good call. That isn't what we want. Although, that is likely what is already happening since https://github.com/docker/hub-tool/pull/167/files#diff-6830a710a038a65c376a407bfafe6dbcba1561c4994fcfb20aff88375403ac37R86 hasn't changed. I'll take a look at that and post a test here once I check it out. Thanks! |
|
I wonder if we can tell if the stored token is a refreshed token (with less rights) or a new token, with full rights. Maybe we should store refresh tokens and new tokens separately, and depending if the command is a |
|
stale, and I do not have any intention of working further on this |
- What I did
Fixes #162, or at least makes it less painful.
A little bit of background...
Upon first login using the
2fa-loginendpoint, a token is returned which gives the user full access to all Hub APIs. When refreshing the token, the resulting token has reduced permissions, and so some APIs that initially worked with the first token will now fail. Until the Hub API is modified to allow refreshed tokens to have the same access as the first token, we need to do another prompt of the user's OTP to get another token which gives the tool full access to the Hub APIs.- How I did it
- How to verify it
Below is output from some commands I ran and the date when they were run to show it working.
Here is the first run with a token that is expired.
Then we run it again within the TTL of the token (30 minutes) and no reprompting of the OTP is required.
One last run shows that the token has expired, again, and we are correctly prompted to provide the OTP for 2FA authentication
- Description for the changelog
- A picture of a cute animal (not mandatory)
