Skip to content

Support oauth2 compatible auth responses (uses access_token field, not token)#174

Open
edwardgeorge wants to merge 1 commit into
camallo:masterfrom
edwardgeorge:master
Open

Support oauth2 compatible auth responses (uses access_token field, not token)#174
edwardgeorge wants to merge 1 commit into
camallo:masterfrom
edwardgeorge:master

Conversation

@edwardgeorge

Copy link
Copy Markdown
Contributor

Adds support for more container registries, eg: Azure (which is what I am attempting to use, requiring this change).

According to the docker specs:

For compatibility with OAuth 2.0, we will also accept token under the name access_token. At least one of these fields must be specified, but both may also appear (for compatibility with older clients). When both are specified, they should be equivalent; if they differ the client's choice is undefined.

Serde doesn't support deriving a Deserialize instance with required fields that may appear under multiple names, so rather than manually implement the complex Deserialize trait here we use an intermediate struct with a simpler TryFrom implementation. No changes to the auth handling logic itself.

Adds support for more container registries, eg: Azure.

According to the docker specs:

    For compatibility with OAuth 2.0, we will also accept token under the name
    access_token. At least one of these fields must be specified, but both may
    also appear (for compatibility with older clients). When both are specified,
    they should be equivalent; if they differ the client's choice is undefined.

Serde doesn't support deriving a Deserialize instance with required fields that
may appear under multiple names, so rather than manually implement the trait
here we use an intermediate struct with a TryFrom implementation.
@steveej steveej self-requested a review September 11, 2020 08:07
@steveej steveej self-assigned this Sep 11, 2020
@edwardgeorge

Copy link
Copy Markdown
Contributor Author

@steveej this PR is perhaps a little more controversial with using the intermediate struct. I favoured this initially as it kept it as part of deserialisation and left the auth logic untouched and ensured that the BearerAuth datatype has a non-optional token field.

An alternative approach is implemented in this branch here: master...edwardgeorge:access_token_getter

If you prefer that method I can overwrite the commit in this PR with the commit from this other branch?
It would be good to get this support in to allow use of the library with, eg, Azure CR which i am presently using this lib against.

@steveej steveej removed their request for review August 4, 2022 14:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants