ducky/devices
ducky/devices/vendor/code.secondbit.org/trout.hg/doc.go
Validate device creation. Update our uuid package to the latest, which is now based on the GitHub fork instead of the Google Code. Also, update our api package to its latest version, which now needs the pqarrays package as a dependency. We fleshed out the validateDeviceCreation. We now pass in the scopes we have (for broad access control) and the user ID (for fine-grained access control). This helper returns the first error it encounters, though it should probably return a slice so we can return multiple errors all at once. Before we even decode the request to create a Device, let's check if the user is even logged in. If we can't ascertain that or they're not, there's no point in even consuming the memory necessary to read the request, because we know we're not going to use it anyways. Finally actually validate the devices we're creating, and return an appropriate error for each error we can get. Also, the api.CheckScopes helper function now takes the scopes passed in as a string slice, and we have an api.GetScopes helper function to retrieve the scopes associated with the request. Let's not keep parsing that. We need two new scopes to control access for device creation; ScopeImport lets users import devices in and is pretty much admin access. ScopeCreateOtherUserDevices allows a user to create Devices that are owned by another user.
| paddy@15 | 1 /* |
| paddy@15 | 2 Package trout provides an opinionated router that's implemented |
| paddy@15 | 3 using a basic trie. |
| paddy@15 | 4 |
| paddy@15 | 5 The router is opinionated and biased towards basic RESTful |
| paddy@15 | 6 services. Its main constraint is that its URL templating is very |
| paddy@15 | 7 basic and has no support for regular expressions, prefix matching, |
| paddy@15 | 8 or anything other than a direct equality comparison, unlike many |
| paddy@15 | 9 routing libraries. |
| paddy@15 | 10 |
| paddy@15 | 11 The router is specifically designed to support users that want to |
| paddy@15 | 12 return correct information with HEAD requests, so it enables users |
| paddy@15 | 13 to retrieve a list of HTTP methods an Endpoint is configured to |
| paddy@15 | 14 respond to. It will not return the configurations an Endpoint is |
| paddy@15 | 15 implicitly configured to respond to by associated a Handler with the |
| paddy@15 | 16 Endpoint itself. These HTTP methods can be accessed through the |
| paddy@15 | 17 Trout-Methods header that is injected into the http.Request object. |
| paddy@15 | 18 Each method will be its own string in the slice. |
| paddy@15 | 19 |
| paddy@15 | 20 The router is also specifically designed to differentiate between a |
| paddy@15 | 21 404 (Not Found) response and a 405 (Method Not Allowed) response. It |
| paddy@15 | 22 will use the configured Handle404 http.Handler when no Endpoint is found |
| paddy@15 | 23 that matches the http.Request's Path property. It will use the |
| paddy@15 | 24 configured Handle405 http.Handler when an Endpoint is found for the |
| paddy@15 | 25 http.Request's Path, but the http.Request's Method has no Handler |
| paddy@15 | 26 associated with it. Setting a default http.Handler for the Endpoint will |
| paddy@15 | 27 result in the Handle405 http.Handler never being used for that Endpoint. |
| paddy@15 | 28 |
| paddy@15 | 29 To map an Endpoint to a http.Handler: |
| paddy@15 | 30 |
| paddy@15 | 31 var router trout.Router |
| paddy@15 | 32 router.Endpoint("/posts/{slug}/comments/{id}").Handler(postsHandler) |
| paddy@15 | 33 |
| paddy@15 | 34 All requests that match that URL structure will be passed to the postsHandler, |
| paddy@15 | 35 no matter what HTTP method they use. |
| paddy@15 | 36 |
| paddy@15 | 37 To map specific Methods to a http.Handler: |
| paddy@15 | 38 |
| paddy@15 | 39 var router trout.Router |
| paddy@15 | 40 router.Endpoint("/posts/{slug}").Methods("GET", "POST").Handler(postsHandler) |
| paddy@15 | 41 |
| paddy@15 | 42 Only requests that match that URL structure will be passed to the postsHandler, |
| paddy@15 | 43 and only if they use the GET or POST HTTP method. |
| paddy@15 | 44 |
| paddy@15 | 45 To access the URL parameter values inside a request, use the RequestVars helper: |
| paddy@15 | 46 |
| paddy@15 | 47 func handler(w http.ResponseWriter, r *http.Request) { |
| paddy@15 | 48 vars := trout.RequestVars(r) |
| paddy@15 | 49 ... |
| paddy@15 | 50 } |
| paddy@15 | 51 |
| paddy@15 | 52 This will return an http.Header object containing the parameter values. They are |
| paddy@15 | 53 passed into the http.Handler by injecting them into the http.Request's Header property, |
| paddy@15 | 54 with the header key of "Trout-Params-{parameter}". The RequestVars helper is just a |
| paddy@15 | 55 convenience function to strip the prefix. Parameters are always passed without the curly |
| paddy@15 | 56 braces. Finally, if a parameter name is used multiple times in a single URL template, values |
| paddy@15 | 57 will be stored in the slice in the order they appeared in the template: |
| paddy@15 | 58 |
| paddy@15 | 59 // for the template /posts/{id}/comments/{id} |
| paddy@15 | 60 // filled with /posts/hello-world/comments/1 |
| paddy@15 | 61 vars := trout.RequestVars(r) |
| paddy@15 | 62 fmt.Println(vars.Get("id")) // outputs `hello-world` |
| paddy@15 | 63 fmt.Println(vars[http.CanonicalHeaderKey("id")]) // outputs `["hello-world", "1"]` |
| paddy@15 | 64 fmt.Println(vars[http.CanonicalHeaderKey("id"})][1]) // outputs `1` |
| paddy@15 | 65 */ |
| paddy@15 | 66 package trout |