Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
docker client: fix requests made against bearer token services #480
Previous to this commit the requests made against a bearer token service would be lacking the
The docker registry relies on the
This commit fixes the issue by reproducing the same request made by the docker client.
In the next sections you can find some debugging logs obtained by running docker and skopeo against a docker registry configured to use Portus as bearer token.
This is the authentication request sent to the bearer token service:
The logs on the docker registry are something like:
As you can see
skopeo - no patch applied
These logs are produced by running this command:
The bearer token service receives this request from skopeo:
As you can see the
Logs from a docker registry using bearer token authentication:
As you can see the
skopeo - patched
I rebuilt skopeo with this patch applied. That solves the issue, the logs produced on the bearer token and on the registry are like the ones of the docker client.
Previous to this commit the requests made against a bearer token service would be lacking the `author` field. That causes the jwt token to have an empty `sub` (Subject) field.  The docker registry relies on the `sub` field to know the author of all the requests. When a registry is configured to send notifications  the resulting webhooks calls will be missing the author too. This commit fixes the issue by reproducing the same request made by the docker client.  https://docs.docker.com/registry/spec/auth/jwt/#getting-a-bearer-token  https://docs.docker.com/registry/configuration/#notifications Signed-off-by: Flavio Castelli <firstname.lastname@example.org>
Overall, sure, more compatibility with Docker is nice (although this is not in the formal spec at https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md ).
OTOH, a server issuing a token with
besides, it seems moby/moby is already doing that as well:
(I wasn't aware honestly)
That’s not a “besides”, that’s the only place I could find that the parameter is ever referenced in the current codebase (in particular, I could not find any consumer in the docker/* universe).
The value used to be documented before docker/distribution@fb481ef#diff-825a2678a7f56e92876b5f3813962a1bL135 (September 2015), but even then it was listed as optional and redundant.
As for a consumer, there is the referenced https://github.com/SUSE/Portus/blob/46bae5fdb488a02022ad5b0f1af59938e8942de2/app/controllers/api/v2/tokens_controller.rb#L31 in Portus, and I can’t see that the use of
Overall, if this were a new protocol proposal, I would be pretty strongly against introducing another field which can be inconsistent with the actually authenticated data; but this is not a concern for the client we are not actually maintaining, while differing from
I agree with that. Thanks for having merged it.