2014-04-15 20:53:12 -04:00
|
|
|
page_title: Registry Documentation
|
|
|
|
page_description: Documentation for docker Registry and Registry API
|
2014-06-08 19:34:47 -04:00
|
|
|
page_keywords: docker, registry, api, hub
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
# The Docker Hub and the Registry spec
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-10-22 08:30:48 -04:00
|
|
|
## The three roles
|
|
|
|
|
|
|
|
There are three major components playing a role in the Docker ecosystem.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
### Docker Hub
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
The Docker Hub is responsible for centralizing information about:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- User accounts
|
|
|
|
- Checksums of the images
|
|
|
|
- Public namespaces
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
The Docker Hub has different components:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- Web UI
|
|
|
|
- Meta-data store (comments, stars, list public repositories)
|
|
|
|
- Authentication service
|
|
|
|
- Tokenization
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-10-22 08:30:48 -04:00
|
|
|
The Docker Hub is authoritative for that information.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-10-22 08:30:48 -04:00
|
|
|
There is only one instance of the Docker Hub, run and
|
2014-04-15 20:53:12 -04:00
|
|
|
managed by Docker Inc.
|
|
|
|
|
|
|
|
### Registry
|
|
|
|
|
2014-10-22 08:30:48 -04:00
|
|
|
The registry has the following characteristics:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- It stores the images and the graph for a set of repositories
|
|
|
|
- It does not have user accounts data
|
|
|
|
- It has no notion of user accounts or authorization
|
2014-06-08 19:34:47 -04:00
|
|
|
- It delegates authentication and authorization to the Docker Hub Auth
|
2014-04-23 16:48:28 -04:00
|
|
|
service using tokens
|
|
|
|
- It supports different storage backends (S3, cloud files, local FS)
|
|
|
|
- It doesn't have a local database
|
2014-07-24 18:19:50 -04:00
|
|
|
- [Source Code](https://github.com/docker/docker-registry)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-10-22 08:30:48 -04:00
|
|
|
We expect that there will be multiple registries out there. To help you
|
2014-04-15 20:53:12 -04:00
|
|
|
grasp the context, here are some examples of registries:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- **sponsor registry**: such a registry is provided by a third-party
|
|
|
|
hosting infrastructure as a convenience for their customers and the
|
2014-10-22 08:30:48 -04:00
|
|
|
Docker community as a whole. Its costs are supported by the third
|
2014-04-23 16:48:28 -04:00
|
|
|
party, but the management and operation of the registry are
|
2014-10-22 08:30:48 -04:00
|
|
|
supported by Docker, Inc. It features read/write access, and delegates
|
2014-06-08 19:34:47 -04:00
|
|
|
authentication and authorization to the Docker Hub.
|
2014-04-23 16:48:28 -04:00
|
|
|
- **mirror registry**: such a registry is provided by a third-party
|
|
|
|
hosting infrastructure but is targeted at their customers only. Some
|
|
|
|
mechanism (unspecified to date) ensures that public images are
|
|
|
|
pulled from a sponsor registry to the mirror registry, to make sure
|
2014-10-22 08:30:48 -04:00
|
|
|
that the customers of the third-party provider can `docker pull`
|
2014-04-23 16:48:28 -04:00
|
|
|
those images locally.
|
|
|
|
- **vendor registry**: such a registry is provided by a software
|
2014-10-22 08:30:48 -04:00
|
|
|
vendor who wants to distribute docker images. It would be operated
|
2014-04-23 16:48:28 -04:00
|
|
|
and managed by the vendor. Only users authorized by the vendor would
|
|
|
|
be able to get write access. Some images would be public (accessible
|
|
|
|
for anyone), others private (accessible only for authorized users).
|
2014-06-08 19:34:47 -04:00
|
|
|
Authentication and authorization would be delegated to the Docker Hub.
|
2014-10-22 08:30:48 -04:00
|
|
|
The goal of vendor registries is to let someone do `docker pull
|
|
|
|
basho/riak1.3` and automatically push from the vendor registry
|
|
|
|
(instead of a sponsor registry); i.e., vendors get all the convenience of a
|
2014-04-23 16:48:28 -04:00
|
|
|
sponsor registry, while retaining control on the asset distribution.
|
|
|
|
- **private registry**: such a registry is located behind a firewall,
|
|
|
|
or protected by an additional security layer (HTTP authorization,
|
|
|
|
SSL client-side certificates, IP address authorization...). The
|
2014-10-22 08:30:48 -04:00
|
|
|
registry is operated by a private entity, outside of Docker's
|
2014-04-23 16:48:28 -04:00
|
|
|
control. It can optionally delegate additional authorization to the
|
2014-06-08 19:34:47 -04:00
|
|
|
Docker Hub, but it is not mandatory.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
> **Note:** The latter implies that while HTTP is the protocol
|
|
|
|
> of choice for a registry, multiple schemes are possible (and
|
|
|
|
> in some cases, trivial):
|
|
|
|
>
|
|
|
|
> - HTTP with GET (and PUT for read-write registries);
|
|
|
|
> - local mount point;
|
|
|
|
> - remote docker addressed through SSH.
|
|
|
|
|
2014-10-22 08:30:48 -04:00
|
|
|
The latter would only require two new commands in Docker, e.g.,
|
2014-04-15 20:53:12 -04:00
|
|
|
`registryget` and `registryput`,
|
|
|
|
wrapping access to the local filesystem (and optionally doing
|
|
|
|
consistency checks). Authentication and authorization are then delegated
|
2014-06-29 21:31:15 -04:00
|
|
|
to SSH (e.g., with public keys).
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
### Docker
|
|
|
|
|
|
|
|
On top of being a runtime for LXC, Docker is the Registry client. It
|
|
|
|
supports:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- Push / Pull on the registry
|
2014-06-08 19:34:47 -04:00
|
|
|
- Client authentication on the Docker Hub
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
## Workflow
|
|
|
|
|
|
|
|
### Pull
|
|
|
|
|
2014-04-24 08:12:21 -04:00
|
|
|
![](/static_files/docker_pull_chart.png)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
1. Contact the Docker Hub to know where I should download “samalba/busybox”
|
|
|
|
2. Docker Hub replies: a. `samalba/busybox` is on Registry A b. here are the
|
2014-04-23 16:48:28 -04:00
|
|
|
checksums for `samalba/busybox` (for all layers) c. token
|
|
|
|
3. Contact Registry A to receive the layers for `samalba/busybox` (all of
|
|
|
|
them to the base image). Registry A is authoritative for “samalba/busybox”
|
|
|
|
but keeps a copy of all inherited layers and serve them all from the same
|
2014-04-15 20:53:12 -04:00
|
|
|
location.
|
2014-06-08 19:34:47 -04:00
|
|
|
4. registry contacts Docker Hub to verify if token/user is allowed to download images
|
|
|
|
5. Docker Hub returns true/false lettings registry know if it should proceed or error
|
2014-04-23 16:48:28 -04:00
|
|
|
out
|
2014-04-15 20:53:12 -04:00
|
|
|
6. Get the payload for all layers
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
It's possible to run:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-15 21:49:05 -04:00
|
|
|
$ sudo docker pull https://<registry>/repositories/samalba/busybox
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
In this case, Docker bypasses the Docker Hub. However the security is not
|
2014-04-23 16:48:28 -04:00
|
|
|
guaranteed (in case Registry A is corrupted) because there won't be any
|
2014-04-15 20:53:12 -04:00
|
|
|
checksum checks.
|
|
|
|
|
|
|
|
Currently registry redirects to s3 urls for downloads, going forward all
|
|
|
|
downloads need to be streamed through the registry. The Registry will
|
|
|
|
then abstract the calls to S3 by a top-level class which implements
|
|
|
|
sub-classes for S3 and local storage.
|
|
|
|
|
|
|
|
Token is only returned when the `X-Docker-Token`
|
|
|
|
header is sent with request.
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Basic Auth is required to pull private repos. Basic auth isn't required
|
2014-04-15 20:53:12 -04:00
|
|
|
for pulling public repos, but if one is provided, it needs to be valid
|
|
|
|
and for an active account.
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
**API (pulling repository foo/bar):**
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
1. (Docker -> Docker Hub) GET /v1/repositories/foo/bar/images:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
|
|
|
X-Docker-Token: true
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Action**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
(looking up the foo/bar in db and gets images and checksums
|
|
|
|
for that repo (all if no tag is specified, if tag, only
|
|
|
|
checksums for those tags) see part 4.4.1)
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
2. (Docker Hub -> Docker) HTTP 200 OK
|
2014-04-23 16:48:28 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=write
|
|
|
|
X-Docker-Endpoints: registry.docker.io [,registry2.docker.io]
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Body**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Jsonified checksums (see part 4.4.1)
|
|
|
|
|
|
|
|
3. (Docker -> Registry) GET /v1/repositories/foo/bar/tags/latest
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=write
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
4. (Registry -> Docker Hub) GET /v1/repositories/foo/bar/images
|
2014-04-23 16:48:28 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=read
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Body**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
<ids and checksums in payload>
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Action**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
(Lookup token see if they have access to pull.)
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
If good:
|
2014-06-08 19:34:47 -04:00
|
|
|
HTTP 200 OK Docker Hub will invalidate the token
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
If bad:
|
|
|
|
HTTP 401 Unauthorized
|
|
|
|
|
|
|
|
5. (Docker -> Registry) GET /v1/images/928374982374/ancestry
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Action**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
(for each image id returned in the registry, fetch /json + /layer)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-18 16:21:55 -04:00
|
|
|
> **Note**:
|
|
|
|
> If someone makes a second request, then we will always give a new token,
|
|
|
|
> never reuse tokens.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
### Push
|
|
|
|
|
2014-04-24 08:12:21 -04:00
|
|
|
![](/static_files/docker_push_chart.png)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
1. Contact the Docker Hub to allocate the repository name “samalba/busybox”
|
2014-04-15 20:53:12 -04:00
|
|
|
(authentication required with user credentials)
|
|
|
|
2. If authentication works and namespace available, “samalba/busybox”
|
|
|
|
is allocated and a temporary token is returned (namespace is marked
|
2014-06-08 19:34:47 -04:00
|
|
|
as initialized in Docker Hub)
|
2014-04-15 20:53:12 -04:00
|
|
|
3. Push the image on the registry (along with the token)
|
2014-06-08 19:34:47 -04:00
|
|
|
4. Registry A contacts the Docker Hub to verify the token (token must
|
2014-04-15 20:53:12 -04:00
|
|
|
corresponds to the repository name)
|
2014-06-08 19:34:47 -04:00
|
|
|
5. Docker Hub validates the token. Registry A starts reading the stream
|
2014-04-15 20:53:12 -04:00
|
|
|
pushed by docker and store the repository (with its images)
|
2014-06-08 19:34:47 -04:00
|
|
|
6. docker contacts the Docker Hub to give checksums for upload images
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
> **Note:**
|
2014-06-08 19:34:47 -04:00
|
|
|
> **It's possible not to use the Docker Hub at all!** In this case, a deployed
|
2014-04-15 20:53:12 -04:00
|
|
|
> version of the Registry is deployed to store and serve images. Those
|
|
|
|
> images are not authenticated and the security is not guaranteed.
|
|
|
|
|
|
|
|
> **Note:**
|
2014-06-08 19:34:47 -04:00
|
|
|
> **Docker Hub can be replaced!** For a private Registry deployed, a custom
|
|
|
|
> Docker Hub can be used to serve and validate token according to different
|
2014-04-15 20:53:12 -04:00
|
|
|
> policies.
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
Docker computes the checksums and submit them to the Docker Hub at the end of
|
|
|
|
the push. When a repository name does not have checksums on the Docker Hub,
|
2014-04-15 20:53:12 -04:00
|
|
|
it means that the push is in progress (since checksums are submitted at
|
|
|
|
the end).
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
**API (pushing repos foo/bar):**
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
1. (Docker -> Docker Hub) PUT /v1/repositories/foo/bar/
|
2014-04-23 16:48:28 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Basic sdkjfskdjfhsdkjfh== X-Docker-Token:
|
|
|
|
true
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Action**:
|
2014-04-23 16:48:28 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
- in Docker Hub, we allocated a new repository, and set to
|
|
|
|
initialized
|
|
|
|
|
|
|
|
**Body**:
|
|
|
|
|
|
|
|
(The body contains the list of images that are going to be
|
|
|
|
pushed, with empty checksums. The checksums will be set at
|
|
|
|
the end of the push):
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
[{“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”}]
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
2. (Docker Hub -> Docker) 200 Created
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
|
|
|
WWW-Authenticate: Token
|
2014-04-23 16:48:28 -04:00
|
|
|
signature=123abc,repository=”foo/bar”,access=write
|
2014-09-09 01:00:23 -04:00
|
|
|
X-Docker-Endpoints: registry.docker.io [, registry2.docker.io]
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
3. (Docker -> Registry) PUT /v1/images/98765432_parent/json
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=write
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
4. (Registry->Docker Hub) GET /v1/repositories/foo/bar/images
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=write
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Action**:
|
|
|
|
|
|
|
|
- Docker Hub:
|
|
|
|
will invalidate the token.
|
|
|
|
- Registry:
|
|
|
|
grants a session (if token is approved) and fetches
|
|
|
|
the images id
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
5. (Docker -> Registry) PUT /v1/images/98765432_parent/json
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
|
|
|
Authorization: Token
|
2014-04-23 16:48:28 -04:00
|
|
|
signature=123abc,repository=”foo/bar”,access=write
|
2014-09-09 01:00:23 -04:00
|
|
|
Cookie: (Cookie provided by the Registry)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
6. (Docker -> Registry) PUT /v1/images/98765432/json
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
|
|
|
Cookie: (Cookie provided by the Registry)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
7. (Docker -> Registry) PUT /v1/images/98765432_parent/layer
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
|
|
|
Cookie: (Cookie provided by the Registry)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
8. (Docker -> Registry) PUT /v1/images/98765432/layer
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
X-Docker-Checksum: sha256:436745873465fdjkhdfjkgh
|
|
|
|
|
|
|
|
9. (Docker -> Registry) PUT /v1/repositories/foo/bar/tags/latest
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
|
|
|
Cookie: (Cookie provided by the Registry)
|
|
|
|
|
|
|
|
**Body**:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
“98765432”
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
10. (Docker -> Docker Hub) PUT /v1/repositories/foo/bar/images
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Basic 123oislifjsldfj== X-Docker-Endpoints:
|
2014-04-15 20:53:12 -04:00
|
|
|
registry1.docker.io (no validation on this right now)
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Body**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
(The image, id`s, tags and checksums)
|
2014-04-15 20:53:12 -04:00
|
|
|
[{“id”:
|
|
|
|
“9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”,
|
|
|
|
“checksum”:
|
|
|
|
“b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”}]
|
|
|
|
|
2014-09-21 20:05:58 -04:00
|
|
|
**Return**:
|
2014-09-09 01:00:23 -04:00
|
|
|
|
|
|
|
HTTP 204
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
> **Note:** If push fails and they need to start again, what happens in the Docker Hub,
|
2014-04-15 20:53:12 -04:00
|
|
|
> there will already be a record for the namespace/name, but it will be
|
|
|
|
> initialized. Should we allow it, or mark as name already used? One edge
|
|
|
|
> case could be if someone pushes the same thing at the same time with two
|
|
|
|
> different shells.
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
If it's a retry on the Registry, Docker has a cookie (provided by the
|
2014-06-08 19:34:47 -04:00
|
|
|
registry after token validation). So the Docker Hub won't have to provide a
|
2014-04-15 20:53:12 -04:00
|
|
|
new token.
|
|
|
|
|
|
|
|
### Delete
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
If you need to delete something from the Docker Hub or registry, we need a
|
2014-04-15 20:53:12 -04:00
|
|
|
nice clean way to do that. Here is the workflow.
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
1. Docker contacts the Docker Hub to request a delete of a repository
|
2014-04-23 16:48:28 -04:00
|
|
|
`samalba/busybox` (authentication required with user credentials)
|
|
|
|
2. If authentication works and repository is valid, `samalba/busybox`
|
|
|
|
is marked as deleted and a temporary token is returned
|
2014-04-15 20:53:12 -04:00
|
|
|
3. Send a delete request to the registry for the repository (along with
|
|
|
|
the token)
|
2014-06-08 19:34:47 -04:00
|
|
|
4. Registry A contacts the Docker Hub to verify the token (token must
|
2014-04-15 20:53:12 -04:00
|
|
|
corresponds to the repository name)
|
2014-06-08 19:34:47 -04:00
|
|
|
5. Docker Hub validates the token. Registry A deletes the repository and
|
2014-04-15 20:53:12 -04:00
|
|
|
everything associated to it.
|
2014-06-08 19:34:47 -04:00
|
|
|
6. docker contacts the Docker Hub to let it know it was removed from the
|
|
|
|
registry, the Docker Hub removes all records from the database.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-18 16:21:55 -04:00
|
|
|
> **Note**:
|
|
|
|
> The Docker client should present an "Are you sure?" prompt to confirm
|
2014-04-23 16:48:28 -04:00
|
|
|
> the deletion before starting the process. Once it starts it can't be
|
2014-04-18 16:21:55 -04:00
|
|
|
> undone.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
**API (deleting repository foo/bar):**
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
1. (Docker -> Docker Hub) DELETE /v1/repositories/foo/bar/
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Basic sdkjfskdjfhsdkjfh== X-Docker-Token:
|
|
|
|
true
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Action**:
|
|
|
|
|
|
|
|
- in Docker Hub, we make sure it is a valid repository, and set
|
|
|
|
to deleted (logically)
|
|
|
|
|
|
|
|
**Body**:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Empty
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
2. (Docker Hub -> Docker) 202 Accepted
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
|
|
|
WWW-Authenticate: Token
|
2014-04-23 16:48:28 -04:00
|
|
|
signature=123abc,repository=”foo/bar”,access=delete
|
2014-09-09 01:00:23 -04:00
|
|
|
X-Docker-Endpoints: registry.docker.io [, registry2.docker.io]
|
2014-04-23 16:48:28 -04:00
|
|
|
# list of endpoints where this repo lives.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
3. (Docker -> Registry) DELETE /v1/repositories/foo/bar/
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=delete
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
4. (Registry->Docker Hub) PUT /v1/repositories/foo/bar/auth
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=delete
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Action**:
|
|
|
|
|
|
|
|
- Docker Hub:
|
|
|
|
will invalidate the token.
|
|
|
|
- Registry:
|
|
|
|
deletes the repository (if token is approved)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
5. (Registry -> Docker) 200 OK
|
|
|
|
|
|
|
|
200 If success 403 if forbidden 400 if bad request 404
|
|
|
|
if repository isn't found
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
6. (Docker -> Docker Hub) DELETE /v1/repositories/foo/bar/
|
2014-04-23 16:48:28 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Headers**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Basic 123oislifjsldfj== X-Docker-Endpoints:
|
|
|
|
registry-1.docker.io (no validation on this right now)
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Body**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Empty
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Return**:
|
|
|
|
|
|
|
|
HTTP 200
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
## How to use the Registry in standalone mode
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
The Docker Hub has two main purposes (along with its fancy social features):
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- Resolve short names (to avoid passing absolute URLs all the time):
|
|
|
|
|
|
|
|
username/projectname ->
|
|
|
|
https://registry.docker.io/users/<username>/repositories/<projectname>/
|
|
|
|
team/projectname ->
|
|
|
|
https://registry.docker.io/team/<team>/repositories/<projectname>/
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- Authenticate a user as a repos owner (for a central referenced
|
2014-04-15 20:53:12 -04:00
|
|
|
repository)
|
|
|
|
|
2014-08-21 14:04:25 -04:00
|
|
|
### Without a Docker Hub
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
Using the Registry without the Docker Hub can be useful to store the images
|
2014-04-15 20:53:12 -04:00
|
|
|
on a private network without having to rely on an external entity
|
|
|
|
controlled by Docker Inc.
|
|
|
|
|
|
|
|
In this case, the registry will be launched in a special mode
|
2014-11-04 23:26:17 -05:00
|
|
|
(-standalone? ne? -no-index?). In this mode, the only thing which changes is
|
2014-06-08 19:34:47 -04:00
|
|
|
that Registry will never contact the Docker Hub to verify a token. It will be
|
2014-04-15 20:53:12 -04:00
|
|
|
the Registry owner responsibility to authenticate the user who pushes
|
|
|
|
(or even pulls) an image using any mechanism (HTTP auth, IP based,
|
|
|
|
etc...).
|
|
|
|
|
|
|
|
In this scenario, the Registry is responsible for the security in case
|
|
|
|
of data corruption since the checksums are not delivered by a trusted
|
|
|
|
entity.
|
|
|
|
|
|
|
|
As hinted previously, a standalone registry can also be implemented by
|
|
|
|
any HTTP server handling GET/PUT requests (or even only GET requests if
|
|
|
|
no write access is necessary).
|
|
|
|
|
2014-08-21 14:04:25 -04:00
|
|
|
### With a Docker Hub
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
The Docker Hub data needed by the Registry are simple:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- Serve the checksums
|
|
|
|
- Provide and authorize a Token
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
In the scenario of a Registry running on a private network with the need
|
2014-06-08 19:34:47 -04:00
|
|
|
of centralizing and authorizing, it's easy to use a custom Docker Hub.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
The only challenge will be to tell Docker to contact (and trust) this
|
2014-06-08 19:34:47 -04:00
|
|
|
custom Docker Hub. Docker will be configurable at some point to use a
|
|
|
|
specific Docker Hub, it'll be the private entity responsibility (basically
|
2014-04-15 20:53:12 -04:00
|
|
|
the organization who uses Docker in a private environment) to maintain
|
2014-06-08 19:34:47 -04:00
|
|
|
the Docker Hub and the Docker's configuration among its consumers.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
## The API
|
|
|
|
|
|
|
|
The first version of the api is available here:
|
|
|
|
[https://github.com/jpetazzo/docker/blob/acd51ecea8f5d3c02b00a08176171c59442df8b3/docs/images-repositories-push-pull.md](https://github.com/jpetazzo/docker/blob/acd51ecea8f5d3c02b00a08176171c59442df8b3/docs/images-repositories-push-pull.md)
|
|
|
|
|
|
|
|
### Images
|
|
|
|
|
|
|
|
The format returned in the images is not defined here (for layer and
|
|
|
|
JSON), basically because Registry stores exactly the same kind of
|
|
|
|
information as Docker uses to manage them.
|
|
|
|
|
|
|
|
The format of ancestry is a line-separated list of image ids, in age
|
2014-04-23 16:48:28 -04:00
|
|
|
order, i.e. the image's parent is on the last line, the parent of the
|
2014-04-15 20:53:12 -04:00
|
|
|
parent on the next-to-last line, etc.; if the image has no parent, the
|
|
|
|
file is empty.
|
|
|
|
|
|
|
|
GET /v1/images/<image_id>/layer
|
|
|
|
PUT /v1/images/<image_id>/layer
|
|
|
|
GET /v1/images/<image_id>/json
|
|
|
|
PUT /v1/images/<image_id>/json
|
|
|
|
GET /v1/images/<image_id>/ancestry
|
|
|
|
PUT /v1/images/<image_id>/ancestry
|
|
|
|
|
|
|
|
### Users
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
### Create a user (Docker Hub)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
POST /v1/users:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Body**:
|
|
|
|
|
2014-07-24 18:19:50 -04:00
|
|
|
{"email": "[sam@docker.com](mailto:sam%40docker.com)",
|
2014-04-23 16:48:28 -04:00
|
|
|
"password": "toto42", "username": "foobar"`}
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Validation**:
|
|
|
|
|
|
|
|
- **username**: min 4 character, max 30 characters, must match the
|
|
|
|
regular expression [a-z0-9_].
|
|
|
|
- **password**: min 5 characters
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-21 20:05:58 -04:00
|
|
|
**Valid**:
|
2014-09-09 01:00:23 -04:00
|
|
|
|
2014-09-08 13:18:13 -04:00
|
|
|
return HTTP 201
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
Errors: HTTP 400 (we should create error codes for possible errors) -
|
|
|
|
invalid json - missing field - wrong format (username, password, email,
|
|
|
|
etc) - forbidden name - name already exists
|
|
|
|
|
2014-04-18 16:21:55 -04:00
|
|
|
> **Note**:
|
|
|
|
> A user account will be valid only if the email has been validated (a
|
|
|
|
> validation link is sent to the email address).
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
### Update a user (Docker Hub)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
PUT /v1/users/<username>
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Body**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
{"password": "toto"}
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-18 16:21:55 -04:00
|
|
|
> **Note**:
|
|
|
|
> We can also update email address, if they do, they will need to reverify
|
|
|
|
> their new email address.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
### Login (Docker Hub)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
Does nothing else but asking for a user authentication. Can be used to
|
|
|
|
validate credentials. HTTP Basic Auth for now, maybe change in future.
|
|
|
|
|
|
|
|
GET /v1/users
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Return**:
|
|
|
|
- Valid: HTTP 200
|
|
|
|
- Invalid login: HTTP 401
|
|
|
|
- Account inactive: HTTP 403 Account is not Active
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
### Tags (Registry)
|
|
|
|
|
|
|
|
The Registry does not know anything about users. Even though
|
2014-04-23 16:48:28 -04:00
|
|
|
repositories are under usernames, it's just a namespace for the
|
2014-04-15 20:53:12 -04:00
|
|
|
registry. Allowing us to implement organizations or different namespaces
|
2014-06-14 17:13:55 -04:00
|
|
|
per user later, without modifying the Registry's API.
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
The following naming restrictions apply:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- Namespaces must match the same regular expression as usernames (See
|
2014-04-15 20:53:12 -04:00
|
|
|
4.2.1.)
|
2014-04-23 16:48:28 -04:00
|
|
|
- Repository names must match the regular expression [a-zA-Z0-9-_.]
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
### Get all tags:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
GET /v1/repositories/<namespace>/<repository_name>/tags
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
**Return**: HTTP 200
|
|
|
|
{ "latest":
|
2014-04-15 20:53:12 -04:00
|
|
|
"9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f",
|
|
|
|
“0.1.1”:
|
|
|
|
“b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087” }
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**4.3.2 Read the content of a tag (resolve the image id):**
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
GET /v1/repositories/<namespace>/<repo_name>/tags/<tag>
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Return**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
"9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f"
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**4.3.3 Delete a tag (registry):**
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
DELETE /v1/repositories/<namespace>/<repo_name>/tags/<tag>
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
### 4.4 Images (Docker Hub)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
For the Docker Hub to “resolve” the repository name to a Registry location,
|
2014-04-15 20:53:12 -04:00
|
|
|
it uses the X-Docker-Endpoints header. In other terms, this requests
|
|
|
|
always add a `X-Docker-Endpoints` to indicate the
|
|
|
|
location of the registry which hosts this repository.
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
**4.4.1 Get the images:**
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
GET /v1/repositories/<namespace>/<repo_name>/images
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
**Return**: HTTP 200
|
|
|
|
[{“id”:
|
2014-04-15 20:53:12 -04:00
|
|
|
“9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”,
|
|
|
|
“checksum”:
|
|
|
|
“[md5:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087](md5:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087)”}]
|
|
|
|
|
|
|
|
### Add/update the images:
|
|
|
|
|
|
|
|
You always add images, you never remove them.
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
PUT /v1/repositories/<namespace>/<repo_name>/images
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Body**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
[ {“id”:
|
2014-04-15 20:53:12 -04:00
|
|
|
“9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”,
|
|
|
|
“checksum”:
|
|
|
|
“sha256:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”}
|
|
|
|
]
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Return**:
|
|
|
|
|
|
|
|
204
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
### Repositories
|
|
|
|
|
|
|
|
### Remove a Repository (Registry)
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
DELETE /v1/repositories/<namespace>/<repo_name>
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
Return 200 OK
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
### Remove a Repository (Docker Hub)
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
This starts the delete process. see 2.3 for more details.
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
DELETE /v1/repositories/<namespace>/<repo_name>
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
Return 202 OK
|
|
|
|
|
|
|
|
## Chaining Registries
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
It's possible to chain Registries server for several reasons:
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- Load balancing
|
|
|
|
- Delegate the next request to another server
|
2014-04-15 20:53:12 -04:00
|
|
|
|
|
|
|
When a Registry is a reference for a repository, it should host the
|
|
|
|
entire images chain in order to avoid breaking the chain during the
|
|
|
|
download.
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
The Docker Hub and Registry use this mechanism to redirect on one or the
|
2014-04-15 20:53:12 -04:00
|
|
|
other.
|
|
|
|
|
|
|
|
Example with an image download:
|
|
|
|
|
|
|
|
On every request, a special header can be returned:
|
|
|
|
|
|
|
|
X-Docker-Endpoints: server1,server2
|
|
|
|
|
|
|
|
On the next request, the client will always pick a server from this
|
|
|
|
list.
|
|
|
|
|
|
|
|
## Authentication & Authorization
|
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
### On the Docker Hub
|
2014-04-15 20:53:12 -04:00
|
|
|
|
2014-06-08 19:34:47 -04:00
|
|
|
The Docker Hub supports both “Basic” and “Token” challenges. Usually when
|
|
|
|
there is a `401 Unauthorized`, the Docker Hub replies
|
2014-04-15 20:53:12 -04:00
|
|
|
this:
|
|
|
|
|
|
|
|
401 Unauthorized
|
|
|
|
WWW-Authenticate: Basic realm="auth required",Token
|
|
|
|
|
|
|
|
You have 3 options:
|
|
|
|
|
|
|
|
1. Provide user credentials and ask for a token
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Header**:
|
|
|
|
|
|
|
|
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
|
|
|
X-Docker-Token: true
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
In this case, along with the 200 response, you'll get a new token
|
|
|
|
(if user auth is ok): If authorization isn't correct you get a 401
|
|
|
|
response. If account isn't active you will get a 403 response.
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Response**:
|
|
|
|
|
|
|
|
200 OK
|
|
|
|
X-Docker-Token: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=read
|
2014-09-21 20:05:58 -04:00
|
|
|
|
2014-04-20 13:27:00 -04:00
|
|
|
|
2014-04-15 20:53:12 -04:00
|
|
|
2. Provide user credentials only
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Header**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
|
2014-04-20 13:27:00 -04:00
|
|
|
|
2014-04-15 20:53:12 -04:00
|
|
|
3. Provide Token
|
|
|
|
|
2014-09-09 01:00:23 -04:00
|
|
|
**Header**:
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
Authorization: Token
|
|
|
|
signature=123abc,repository=”foo/bar”,access=read
|
2014-04-20 13:27:00 -04:00
|
|
|
|
2014-04-15 20:53:12 -04:00
|
|
|
### 6.2 On the Registry
|
|
|
|
|
|
|
|
The Registry only supports the Token challenge:
|
|
|
|
|
|
|
|
401 Unauthorized
|
|
|
|
WWW-Authenticate: Token
|
|
|
|
|
|
|
|
The only way is to provide a token on `401 Unauthorized`
|
|
|
|
responses:
|
|
|
|
|
|
|
|
Authorization: Token signature=123abc,repository="foo/bar",access=read
|
|
|
|
|
|
|
|
Usually, the Registry provides a Cookie when a Token verification
|
|
|
|
succeeded. Every time the Registry passes a Cookie, you have to pass it
|
|
|
|
back the same cookie.:
|
|
|
|
|
|
|
|
200 OK
|
|
|
|
Set-Cookie: session="wD/J7LqL5ctqw8haL10vgfhrb2Q=?foo=UydiYXInCnAxCi4=×tamp=RjEzNjYzMTQ5NDcuNDc0NjQzCi4="; Path=/; HttpOnly
|
|
|
|
|
|
|
|
Next request:
|
|
|
|
|
|
|
|
GET /(...)
|
|
|
|
Cookie: session="wD/J7LqL5ctqw8haL10vgfhrb2Q=?foo=UydiYXInCnAxCi4=×tamp=RjEzNjYzMTQ5NDcuNDc0NjQzCi4="
|
|
|
|
|
|
|
|
## Document Version
|
|
|
|
|
2014-04-23 16:48:28 -04:00
|
|
|
- 1.0 : May 6th 2013 : initial release
|
|
|
|
- 1.1 : June 1st 2013 : Added Delete Repository and way to handle new
|
2014-04-15 20:53:12 -04:00
|
|
|
source namespace.
|
|
|
|
|