Commit graph

15 commits

Author SHA1 Message Date
Stephen Day
42577c6bde Merge pull request #20 from stevvooe/api-specification-detail
Fill in detail for V2 registry api specification
2015-01-06 10:04:06 -08:00
Brian Bland
ea6c082e85 Minor cleanup/testing for HMAC upload tokens
Changes configuration variable, lowercases private interface methods,
adds token sanity tests.
2015-01-05 14:37:56 -08:00
Brian Bland
07ba5db168 Serializes upload state to an HMAC token for subsequent requests
To support clustered registry, upload UUIDs must be recognizable by
registries that did not issue the UUID. By creating an HMAC verifiable
upload state token, registries can validate upload requests that other
instances authorized. The tokenProvider interface could also use a redis
store or other system for token handling in the future.
2015-01-05 14:27:05 -08:00
Stephen J Day
71819ac9c3 Use full json content type with charset parameter 2015-01-02 10:49:10 -08:00
Olivier Gambier
67ca9d10cf Move from docker-registry to distribution 2014-12-23 17:13:02 -08:00
Stephen J Day
b1f36c3fe5 Ensure that unset Context.Name only allowed on base route
If Context.Name is not set, the acceess controller may allow an unintended
request through. By only allowing a request to proceed without a name on the
base route, we provide some protection if future bugs forget to set the context
properly.
2014-12-18 17:25:06 -08:00
Stephen J Day
d0a9e9b475 Integrate auth.AccessController into registry app
This changeset integrates the AccessController into the main registry app. This
includes support for configuration and a test implementation, called "silly"
auth. Auth is only enabled if the configuration is present but takes measure to
ensure that configuration errors don't allow the appserver to start with open
access.
2014-12-18 12:34:56 -08:00
Stephen J Day
d08f0edcf1 Migrate references to consolidated v2 package
Routes and errors are now all referenced from a single v2 package. This
packages exports are acceptable for use in the server side as well as
integration into docker core.
2014-12-12 15:36:15 -08:00
Stephen J Day
83f882b427 Migrate webapp to use exported urls.URLBuilder package 2014-12-12 15:36:15 -08:00
Stephen J Day
5b13e95511 Porting registry to use urls package
This simply moves the registry app to be using the urls package and its
exported route names. This supports locking down exported route definitions for
use in client packages.
2014-12-12 15:36:15 -08:00
Stephen J Day
76929fb63f Implement V2 API base endpoint
This implements a base endpoint that will respond with a 200 OK and an empty
json response. Such an endpoint can be used as to ping the v2 service or as an
endpoint to check authorization status.
2014-12-10 22:43:45 -08:00
Stephen J Day
e809796f59 Initial implementation of Manifest HTTP API
Push, pull and delete of manifest files in the registry have been implemented
on top of the storage services. Basic workflows, including reporting of missing
manifests are tested, including various proposed response codes. Common testing
functionality has been collected into shared methods. A test suite may be
emerging but it might better to capture more edge cases (such as resumable
upload, range requests, etc.) before we commit to a full approach.

To support clearer test cases and simpler handler methods, an application aware
urlBuilder has been added. We may want to export the functionality for use in
the client, which could allow us to abstract away from gorilla/mux.

A few error codes have been added to fill in error conditions missing from the
proposal. Some use cases have identified some problems with the approach to
error reporting that requires more work to reconcile. To resolve this, the
mapping of Go errors into error types needs to pulled out of the handlers and
into the application. We also need to move to type-based errors, with rich
information, rather than value-based errors. ErrorHandlers will probably
replace the http.Handlers to make this work correctly.

Unrelated to the above, the "length" parameter has been migrated to "size" for
completing layer uploads. This change should have gone out before but these
diffs ending up being coupled with the parameter name change due to updates to
the layer unit tests.
2014-11-26 13:35:07 -08:00
Stephen J Day
e158e3cd65 Initial implementation of Layer API
The http API has its first set of endpoints to implement the core aspects of
fetching and uploading layers. Uploads can be started and completed in a single
chunk and the content can be fetched via tarsum. Most proposed error conditions
should be represented but edge cases likely remain.

In this version, note that the layers are still called layers, even though the
routes are pointing to blobs. This will change with backend refactoring over
the next few weeks.

The unit tests are a bit of a shamble but these need to be carefully written
along with the core specification process. As the the client-server interaction
solidifies, we can port this into a verification suite for registry providers.
2014-11-21 19:12:20 -08:00
Stephen J Day
5789ca7629 Update routes to reflect specification changes
To bring the implementation inline with the specification, the names and
structure of the API routes have been updated.

The overloaded term "image" has been replaced with the term "manifest", which
may also be known as "image manifest".  The desire for the layer storage to be
more of a general blob storage is reflected in moving from "layer" api prefixes
to "blob". The "tarsum" path parameter has been replaced by a more general
"digest" parameter and is no longer required to start uploads. Another set of
changes will come along to support this change at the storage service layer.
2014-11-18 20:39:32 -08:00
Stephen J Day
22c9f45598 Carve out initial application structure
This changeset defines the application structure to be used for the http side
of the new registry. The main components are the App and Context structs. The
App context is instance global and manages global configuration and resources.
Context contains request-specific resources that may be created as a by-product
of an in-flight request.

To latently construct per-request handlers and leverage gorilla/mux, a dispatch
structure has been propped up next to the main handler flow. Without this, a
router and all handlers need to be constructed on every request. By
constructing handlers on each request, we ensure thread isolation and can
carefully control the security context of in-flight requests. There are unit
tests covering this functionality.
2014-11-10 19:03:49 -08:00