403 handling about hub-tool

[ingshtrom]

While I agree we need a better error message, this seems like an oversight on the Hub side of things (probably a decision made well before most of us were here) because as things work right now Linux users will not be able to use all of the hub-tool features as you cannot log into the CLI with username + password if you have 2FA turned on

❯ docker login -u ahokanson
Password:
Error response from daemon: Get https://registry-1.docker.io/v2/: unauthorized: please use personal access token to login

Thus we're alienating our Linux users even more by releasing this tool, IMO.

In addition, I would 👍 @thaJeztah as we don't want logic all across our properties checking the login password to see if it is a username or password.

[silvin-lubecki]

@chris-crone actually the backend returns this:

{
    "message": "access to the resource is forbidden with personal access token"
}

[ingshtrom]

I thought tokens were global access since we don't actually have any scoping on the tokens (well, I guess RO tokens merged last week, but my OG token was prior to that)?

[silvin-lubecki]

Hmm I wasn't aware of that, I thought tokens had full scope right now... Good to know... I wonder if there's a way to detect the user is using a token as password ?
cc @thaJeztah

[shawnaxsom]

@silvin-lubecki Tokens without scope have full scope, acting as they have in the past.

Tokens have some restrictions even before scope was introduced. You can't log into the UI, for one. Tokens can't create new JWTs in this test case: https://github.com/docker/saas-mega/blob/cb4b110aacccb4fefee6584add5dde98fb025a49/services/repos-new/system-tests/accounts/users_test.go#L170

For detecting token versus password in Hub, we just check if the password entered looks like a UUID. Maybe you can check for UUID, then if it is a UUID, attempt to use it: https://github.com/docker/saas-mega/blob/cb4b110aacccb4fefee6584add5dde98fb025a49/services/hub-garant/hub/authenticate.go#L114

[thaJeztah]

Detecting if it's a UUID could work as a "quick fix" (which could be fine for now, as this tool would still be a "preview". Preferably, we should address HUB-3187 for that though.

It may be somewhat tricky still though, as the reason for actions not working could be many (incorrect password, no access to organisation, not the right permissions for the action, or even "not logged in"), many (all?) of those also applying on password authentication. There's also the risk of exposing information; i.e. "non existing" and "non-accessible" private content should be indistinguishable from each other (given; more a concern for images/tags as the existence of organisations and user-accounts are (afaik) public information).

Some other thoughts;

• Instead of trying to detect the reason, produce a more descriptive error (the provided credentials don't have permissions for this action / no credentials provided)
• could Docker Hub return a more detailed error, based on the specific conditions? (i.e., "credentials were accepted, but don't have the right scope", which would only be returned if the credentials do have (read) access to the resource, but don't have permissions for the action. If the credentials don't have access to the resource, then return a generic "403" or "404".

[chris-crone]

Arg.. Too many things to fix in this thread :)

@ingshtrom, we should definitely fix this on Linux with something like what aws-okta provides for 2FA. Not sure if @thaJeztah has seen this asked for on docker/cli already?

@thaJeztah, it would be great if we could improve the Hub error descriptions.

For getting this tool out into the world, I'd suggest that on getting a 403 with a password structured as a UUID, we catch this in the CLI and output:

<original error>
Personal access tokens are not able to perform all Docker Hub operations, login with a username and password to use this functionality

[chris-crone]

@silvin-lubecki ha, so that makes it a lot easier :)