Merge ~pappacena/launchpad:refactor-oci-push-auth into launchpad:master
Status: | Merged |
---|---|
Approved by: | Thiago F. Pappacena |
Approved revision: | a0addb5c5e0fe4b3698c58466ca0b283a81fb782 |
Merge reported by: | Otto Co-Pilot |
Merged at revision: | not available |
Proposed branch: | ~pappacena/launchpad:refactor-oci-push-auth |
Merge into: | launchpad:master |
Diff against target: |
455 lines (+157/-83) 3 files modified
lib/lp/oci/interfaces/ocipushrule.py (+1/-1) lib/lp/oci/model/ociregistryclient.py (+88/-38) lib/lp/oci/tests/test_ociregistryclient.py (+68/-44) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Tom Wardill (community) | Approve | ||
Colin Watson (community) | Approve | ||
Review via email: mp+384052@code.launchpad.net |
Commit message
Refactoring OCIRegistryClient to prepare for DockerHub.
Dockerhub authentication seems to need token authorization, and the way OCIRegistryClient is structured today (with HTTP Basic auth) makes it a bit difficult to keep the token. This refactoring creates a couple of differente "HTTP clients": one for the registry protocol we have today, and another for DocherHub (to be implemented in another MP).
Description of the change
Summary of reorganization:
- Creation of RegistryHTTPClient helper class, that holds authentication information and does the HTTP requests to registry. That's where DockerHub auth will be implemented in the future.
- OCIRegistryClie
- Changed the tests to use instances of RegistryHTTPClient instead of tuple of auth information
- Changed the tests to use RegistryHTTPCli
- Not really necessary for the tests we have, but I've changed the fake layers files to be a bit more realistic (it's helping me to debug things on dockerhub, and I guess it doesn't hurt to make it a bit closer to reality here).
In the end, a lot of lines got changes, but nothing should have changed in the behavior.
I like the approach of wrapping urlfetch to handle the different authentication methods, this seems pretty extensible for the future.
However, I think there's a better way to determine which client and auth method to use rather than just hardcoding the registry url.
Doing `docker login` with the client makes a request to <registry url>/v2/ (See: https:/ /docs.docker. com/registry/ spec/api/ #api-version- check). This is a call that requires authentication, so making it without the auth will fail. However, it does include the required authentication method in the response headers: `Www-Authenticate: Bearer realm="https:/ /auth.docker. io/token",service= "registry. docker. io"`. docker- registry" `
A registry that uses Basic (like ROCKS) looks like: `Www-Authenticate: Basic realm="
Given this, I think we can rename the `DockerHubHTTPC lient` to something like `BearerTokenReg istryClient` or similar.
The flow will then look similar to how the cli client does:
1. Make request to /v2/ (`docker login`)
2. Work out which client to use from the response header
(3. Optionally get the bearer token if we're doing that method)
4. Make further requests
The spec does state that auth requirements can differ per resource requested, but I think we can miss that for now (It doesn't seem to apply to either ROCKS or DockerHub as yet)