-
Notifications
You must be signed in to change notification settings - Fork 155
Add support for getting token from login #108
Add support for getting token from login #108
Conversation
|
Why |
The auth response will return an identity token from a login when long lived token authentication is supported. The identity token can be used in the auth config in place of basic authentication to get registry access tokens. Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
98afac4 to
7b3e5c8
Compare
|
@MHBauer trying to be consistently inconsistent. Not sure why the responses use CamelCase and the auth type doesn't but I would rather match the case of the field structs. |
|
LGTM although I'd rather wait until we have a PR in docker/docker to handle this before merging it. |
|
@calavera I have no problem waiting to merge |
|
We are ready to open up a PR on docker/docker now that distribution/distribution#1475 has been merged. |
|
LGTM @calavera: Are you okay with merging this now, with the Docker Engine PR coming later today? Then the engine PR will be able to vendor a real |
Add support for getting token from login
|
Merged! 🎉 |
|
@calavera: Thanks! |
|
|
||
| // IdentityToken is used to authenticate the user and get | ||
| // an access token for the registry. | ||
| IdentityToken string `json:"identitytoken,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I'm late to this party, but I do feel that @calavera comment in moby/moby#20970 (comment) does seem to make sense. Do we need a new field if IdentityToken and Password are mutually exclusive? I wouldn't fight for it much if there's a nice benefit in doing it this way. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are mutually exclusive but either way a field would be required in order to differentiate the secret type. For storage of the auth config I think it is fine to combine the "secret" information into a single field which could be the focus of protection, but at this point in the code having a fully enumerated structure is in my opinion the better design.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @aaronlehmann for clarifying for me: Password is sent with basic auth, but IdentityToken goes over Authorization: Bearer ..., so the client does need to know which one it is dealing with.
The auth response will return an identity token from a login when long lived token authentication is supported. The identity token can be used in the auth config in place of basic authentication to get registry access tokens.
See distribution/distribution#1418 for further context on supporting long lived oauth tokens.