http://code.secondbit.org/ducky/devices/ en-us ducky/devices Changelog http://code.secondbit.org/ducky/devices/rev/ed1b5ba69551 http://code.secondbit.org/ducky/devices/rev/ed1b5ba69551 changeset ed1b5ba69551 branch default bookmark tag tip user Paddy <paddy@impractical.co> description Add updating devices to apiv1.

We needed a way to be able to update devices after they were created. This is
supported in the devices package, we just needed to expose it using apiv1
endpoints.

In doing so, it became apparent that allowing users to change the Owner of their
Devices wasn't properly thought through, and pending a reason to use it, I'm
just removing it. The biggest issue came when trying to return usable error
messages; we couldn't distinguish between "you don't own the device you're
trying to update" and "you're not allowed to change the owner of the device". I
also couldn't figure out _who should be able to_ change the owner of the device,
which is generally an indication that I'm building a feature before I have a use
case for it.

To support this change, the apiv1.DeviceChange type needed its Owner property
removed.

I also needed to add deviceFromAPI and devicesFromAPI helpers to return
devices.Device types from apiv1.Device types.

There's now a new validateDeviceUpdate helper that checks to ensure that a
device update request is valid and the user has the appropriate permissions.

The createRequest type now accepts a slice of Devices, not a slice of
DeviceChanges, because we want to pass the Owner in.

A new updateRequest type is created, which accepts a DeviceChange to apply.

A new handleUpdateDevice handler is created, which is assigned to the endpoint
for PATCH requests against a device ID. It checks that the user is logged in,
the Device they're trying to update exists, and that it's a valid update. If all
of that is true, the device is updated and the updated device is returned.

Finally, we had to add two new scopes to support new functionality:
ScopeUpdateOtherUserDevices allows a user to update other user's devices, and
ScopeUpdateLastSeen allows a user to update the LastSeen property of a device.

Pending some better error messages, this should be a full implementation of
updating a device, which leaves only the deletion endpoint to deal with. files apiv1/devices.go
apiv1/endpoints.go
apiv1/handlers.go
apiv1/scopes.go
]]> Paddy <paddy@impractical.co> Sat, 02 Jan 2016 16:36:23 -0800 http://code.secondbit.org/ducky/devices/rev/51ad0db105c8 http://code.secondbit.org/ducky/devices/rev/51ad0db105c8 changeset 51ad0db105c8 branch bookmark tag user Paddy <paddy@impractical.co> description Update trout to fix routing bug.

Update to tip on trout to fix the routing bug that was causing us such issues.
See the commit message of trout at 3df515f0cec5 for more details. files Godeps/Godeps.json
vendor/code.secondbit.org/trout.hg/route.go
]]> Paddy <paddy@impractical.co> Sat, 02 Jan 2016 16:08:43 -0800 http://code.secondbit.org/ducky/devices/rev/b2fdf827758e http://code.secondbit.org/ducky/devices/rev/b2fdf827758e changeset b2fdf827758e branch bookmark tag user Paddy <paddy@impractical.co> description Add endpoint for retrieving devices.

Add an endpoint for retrieving devices, either as a list or by ID.

Stub endpoints for updating and deleting devices., along with TODOs marking them
as things to still be completed. (Right now, accessing those endpoints is an
insta-panic.)

Simplify our handleCreateDevices by returning StatusUnauthorized if AuthUser
fails, so we can reserve StatusForbidden for when auth succeeds but access is
still denied. Also, delay the instantiation and allocation of a Response
variable until we're actually going to use it.

Create a handleGetDevices handler that authenticates the user, and if no ID is
set, returns a list of all their Devices. If one or more IDs are set, only those
Devices are returned. If ScopeViewPushToken is one of the scopes associated with
the request, the push tokens for each Device will be included in the response.
Otherwise, they will be omitted. files apiv1/endpoints.go
apiv1/handlers.go
apiv1/scopes.go
]]> Paddy <paddy@impractical.co> Tue, 22 Dec 2015 06:57:07 -0500 http://code.secondbit.org/ducky/devices/rev/ad63b888f899 http://code.secondbit.org/ducky/devices/rev/ad63b888f899 changeset ad63b888f899 branch bookmark tag user Paddy <paddy@impractical.co> description Fix JSON pointers in errors when creating devices.

Our JSON pointers used to point at the root of the document, but the properties
were actually in objects in an array keyed off of "devices", so we had to update
the field property of our errors to match.

While we were in there, we fixed the "insufficient" error for a Device's name to
be "missing" when the name is an empty string. So far, the only way for a
Device's name for it to be insufficient is _for it to be the empty string_, but
if in the future we raise the minimum length of the Device name, there will be a
distinction and I'd like the code to recognise it. files apiv1/handlers.go
]]> Paddy <paddy@impractical.co> Sat, 19 Dec 2015 00:30:16 -0800 http://code.secondbit.org/ducky/devices/rev/a700ede02f91 http://code.secondbit.org/ducky/devices/rev/a700ede02f91 changeset a700ede02f91 branch bookmark tag user Paddy <paddy@impractical.co> description 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. files Godeps/Godeps.json
apiv1/devices.go
apiv1/handlers.go
apiv1/scopes.go
devices.go
vendor/code.google.com/p/go-uuid/uuid/LICENSE
vendor/code.google.com/p/go-uuid/uuid/dce.go
vendor/code.google.com/p/go-uuid/uuid/doc.go
vendor/code.google.com/p/go-uuid/uuid/hash.go
vendor/code.google.com/p/go-uuid/uuid/json.go

]]> Paddy <paddy@impractical.co> Sat, 19 Dec 2015 00:18:25 -0800 http://code.secondbit.org/ducky/devices/rev/c24a6c5fcd8c http://code.secondbit.org/ducky/devices/rev/c24a6c5fcd8c changeset c24a6c5fcd8c branch bookmark tag user Paddy <paddy@impractical.co> description Begin implementation on apiv1.

Begin implementing the apiv1 package, which will define the first iteration of
our API endpoints and logic. Each API package should be self-contained and able
to run without depending on each other. Think of them as interfaces into
manipulating the business logic defined in the devices package. The point is to
have total control over backwards compatibility, as long as our business logic
doesn't change. If that happens, we're in a bad place, but not as bad as it
could be.

This required us to pull in all our API tools; the api package, its
dependencies, the scopeTypes package (so we can define scopes for our API), the
trout router, etc. We also updated uuid to the latest, which now includes a
license. Hooray?

The new apiv1 package consists of a few things:

* The devices.go file defines the types the API will use to communicate, along
with some helpers to convert from API types to devices types. There's also a
stub for validating the device creation requests, which I haven't implemented
yet because I'm a pretty bad person.
* endpoints.go just contains a helper function that builds our routes and
assigns handlers to them, giving us an http.Handler in the returns that we can
listen with.
* handlers.go defines our HTTP handlers, which will read requests and write
responses, after doing the appropriate validation and executing the
appropriating business logic. Right now, we only have a handler for creating
devices, and it doesn't actually do any validation. Also, we have some
user-correctable errors being returned as 500s right now, which is Bad.
Fortunately, they're all marked with BUG, so I can at least come back to them.
* response.go defines the Response type that will be used for returning
information after a request is executed. It may eventually get some helpers,
but for now it's pretty basic.
* scopes.go defines the Scopes that we're going to be using in the package to
control access. It should probably (eventually) include a helper to register
the Scopes, or we should have a collector service that pulls in all the
packages, finds all their Scopes, and registers them. I haven't decided how I
want to manage Scope registration just yet.

We exported the getStorer function (now GetStorer) so other packages can use it.
I'm not sure how I feel about this just yet. We also had to create a WithStorer
helper method that embeds the Storer into a context.Context, so we can bootstrap
in devicesd.

We erroneously had Created in the DeviceChange struct, but there's no reason the
Created property of a Device should ever change, so it was removed from the
logic, from the struct, and from the tests.

Our CreateMany helper was erroneously creating the un-modified Devices that were
passed in, instead of the Devices that had sensible defaults filled.

We created a _very minimal_ (e.g., needs some work before it's ready for
production) devicesd package that will spin up a simple server, just so we could
take a peek at our apiv1 endpoints as they'd actually be used. (It worked. Yay?)
We should continue to expand on this with configuration, more information being
logged, etc. files .hgignore
Godeps/Godeps.json
apiv1/devices.go
apiv1/endpoints.go
apiv1/handlers.go
apiv1/response.go
apiv1/scopes.go
context.go
devices.go
devicesd/server.go

]]> Paddy <paddy@impractical.co> Mon, 14 Dec 2015 00:12:33 -0800 http://code.secondbit.org/ducky/devices/rev/1ae5bae472c1 http://code.secondbit.org/ducky/devices/rev/1ae5bae472c1 changeset 1ae5bae472c1 branch bookmark tag user Paddy <paddy@impractical.co> description Set up DeleteDevices in Memstore.

Implement the DeleteDevices method for our Memstore, removing the Devices
specified by the passed IDs.

Also, create a simple test that verifies that when Devices are deleted, only the
Devices you intend to delete are actually deleted. Further tests should be
written to verify that this extends to ListDevicesByOwner (e.g., deleted devices
will not be returned when listing them), CreateDevices (e.g., will not result in
an ErrDeviceAlreadyExists error), and UpdateDevice (e.g., will return an
ErrDeviceNotFound error after the Device is deleted).

But for now, we're confident that it works in the simplest possible case. files memstore.go
storer_test.go
]]> Paddy <paddy@impractical.co> Sun, 29 Nov 2015 21:31:47 -0800 http://code.secondbit.org/ducky/devices/rev/e3ced527d4ab http://code.secondbit.org/ducky/devices/rev/e3ced527d4ab changeset e3ced527d4ab branch bookmark tag user Paddy <paddy@impractical.co> description Add tests for ToSlice and ToMap.

Add simple unit tests that verify that ToSlice and ToMap both work as we expect.
These are probably overly-simplistic, but so are the functions we're testing.
Not sure about this... feel a bit conflicted. But let's try it. files devices_test.go
]]> Paddy <paddy@impractical.co> Sun, 29 Nov 2015 19:46:20 -0800 http://code.secondbit.org/ducky/devices/rev/03c49b4d3d9f http://code.secondbit.org/ducky/devices/rev/03c49b4d3d9f changeset 03c49b4d3d9f branch bookmark tag user Paddy <paddy@impractical.co> description Add doc comments to all our exported types.

It makes golint happy, and it's a good thing to do. It's kind of shameful that
we went so long without them. Oops. files devices.go
memstore.go
]]> Paddy <paddy@impractical.co> Sat, 28 Nov 2015 18:26:03 -0800 http://code.secondbit.org/ducky/devices/rev/683050b4546b http://code.secondbit.org/ducky/devices/rev/683050b4546b changeset 683050b4546b branch bookmark tag user Paddy <paddy@impractical.co> description Return ErrDeviceNotFound when updating devices.

If we can't find the Device we're supposed to update, return an
ErrDeviceNotFound error.

Write a unit test that tests for this behaviour. files memstore.go
storer_test.go
]]> Paddy <paddy@impractical.co> Fri, 27 Nov 2015 11:32:15 -0800