http://code.secondbit.org/auth/ en-us auth Changelog http://code.secondbit.org/auth/rev/cd5f07f9811b http://code.secondbit.org/auth/rev/cd5f07f9811b changeset cd5f07f9811b branch default bookmark tag tip user Paddy <paddy@impractical.co> description Update nsq import path.

go-nsq has moved to nsqio/go-nsq, so we need to update the import path
appropriately. files listeners/email_verification/listener.go
]]> Paddy <paddy@impractical.co> Mon, 14 Dec 2015 04:36:28 -0800 http://code.secondbit.org/auth/rev/b7e685839a1b http://code.secondbit.org/auth/rev/b7e685839a1b changeset b7e685839a1b branch bookmark tag user Paddy <paddy@impractical.co> description Break out scopes and events.

This repo has gotten unwieldy, and there are portions of it that need to be
imported by a large number of other packages.

For example, scopes will be used in almost every API we write. Rather than
importing the entirety of this codebase into every API we write, I've opted to
move the scope logic out into a scopes package, with a subpackage for the
defined types, which is all most projects actually want to import.

We also define some event type constants, and importing those shouldn't require
a project to import all our dependencies, either. So I made an events subpackage
that just holds those constants.

This package has become a little bit of a red-headed stepchild and is do for a
refactor, but I'm trying to put that off as long as I can.

The refactoring of our scopes stuff has left a bug wherein a token can be
granted for scopes that don't exist. I'm going to need to revisit that, and also
how to limit scopes to only be granted to the users that should be able to
request them. But that's a battle for another day. files authcode.go
authcode_test.go
authd/server.go
client.go
client/login.go
config.go
context.go
events/profile.go
memstore.go
oauth2.go

]]> Paddy <paddy@impractical.co> Mon, 14 Dec 2015 04:17:21 -0800 http://code.secondbit.org/auth/rev/4b68bac597b7 http://code.secondbit.org/auth/rev/4b68bac597b7 changeset 4b68bac597b7 branch bookmark tag user Paddy <paddy@secondbit.org> description Update client to detect errors.

The client doesn't treat non-200 responses as errors automatically, so we need
to detect when the response.Errors property is set, and use that to return an
error. To avoid the boilerplate and an extensive error system, I just wrapped
them in an httpErrors type that implements the error interface. That way the
errors can be returned, and callers can type-cast and interrogate them. I also
updated the GetLogin function to return an auth.ErrLoginNotFound error when the
httpErrors response indicates that's the reason the request failed. files client/client.go
client/login.go
]]> Paddy <paddy@secondbit.org> Sat, 18 Jul 2015 03:38:27 -0400 http://code.secondbit.org/auth/rev/7bba108d2d9a http://code.secondbit.org/auth/rev/7bba108d2d9a changeset 7bba108d2d9a branch bookmark tag user Paddy <paddy@secondbit.org> description Send events when logins are verified.

Add an ActionLoginVerified constant to use as the action when a login has been
verified. On second thought, this should probably just be "verified", huh? Then
we can reuse it across models. Oops.

We also added a call to send a login verified event to NSQ when the login is
verified. files profile.go
]]> Paddy <paddy@secondbit.org> Sat, 18 Jul 2015 03:36:13 -0400 http://code.secondbit.org/auth/rev/0a2c3d677161 http://code.secondbit.org/auth/rev/0a2c3d677161 changeset 0a2c3d677161 branch bookmark tag user Paddy <paddy@secondbit.org> description Update to use a generic event emitter.

Rather can creating a purpose-built event emitter for each and every event we
need to emit (I'm looking at you, login verification event) which is _downright
silly_, we're now using a generic event publisher that's based on saying "HEY A
MODEL UPDATED".

This means we need to change all our setup code in authd to use
events.NewNSQPublisher or events.NewStdoutPublisher instead of our homegrown
solutions. Which also means updating our config to take an events.Publisher
instead of our LoginVerificationNotifier (blergh).

Our Context also now uses an events.Publisher instead of a
LoginVerificationNotifier. Party all around! We also replaced our
SendLoginVerification helper method on Context with a SendModelEvent helper
method on Context, which is just a light wrapper around
events.PublishModelEvent.

Of course, all this means we need to update our email_verification listener to
listen to the correct channel (based on the model we want updates about) and
filter down to a Created action or our new custom action for "the customer wants
their verification resent", which I'm OK making a special case and not generic,
because c'mon. But we had a subtle change to all our constants, some of which
are unofficial constants now. I'm unsure how I feel about this.

We also updated our email_verification listener so that we're unmarshalling to a
custom loginEvent, which is just an events.Event that overwrites the Data
property to be an auth.Login instance. This is to make sure we don't need to
wrangle a map[string]interface{}, which is no fun. I'm also OK with
special-casing like this, because it's 1) a tiny amount of code, 2) properly
utilising composition, and 3) the only way I can think of to cleanly accomplish
what I want.

I also added a note about GetLogin's deficient handling of logins, namely that
it doesn't recognise admins and return Verification codes to them, which would
be a useful property for internal tools to take advantage of. Ah well.

I updated the Profile and Login implementations so they're now event.Model
instances, mainly by just exporting some strings from them through getters that
will let us automatically build an Event from them. This lets us use the
PublishModelEvent helper.

I updated our CreateProfileHandler to properly mangle the login Verification
property, and to fire off the ActionCreated events for the new Login and the new
Profile.

I updated our GetLoginHandler and UpdateLoginHandler to properly mangle the
loginVerification property. God that's annoying. :-/

You'll note I didn't start publishing the events.ActionUpdated or
events.ActionDeleted events for Profiles or Logins yet, and didn't bother
publishing any events for literally any other type. That's because I'm a lazy
piece of crap and will end up publishing them when I absolutely have to. Part of
that is because if a channel isn't created/being read for a topic, the messages
will just stack up in NSQ, and I don't want that. But mostly I'm lazy.

Finally, I got to delete the entire profile_verification.go file, because we're
no longer special-casing that. Hooray! files authd/server.go
config.go
context.go
listeners/email_verification/listener.go
profile.go
profile_verification.go
]]> Paddy <paddy@secondbit.org> Wed, 15 Jul 2015 00:13:59 -0400 http://code.secondbit.org/auth/rev/5d52b9d83184 http://code.secondbit.org/auth/rev/5d52b9d83184 changeset 5d52b9d83184 branch bookmark tag user Paddy <paddy@secondbit.org> description Add notes about model events.

We need to sensibly trigger events about models, so I left some basic notes
about triggering an event when a Profile is created. files profile.go
]]> Paddy <paddy@secondbit.org> Mon, 13 Jul 2015 23:49:25 -0400 http://code.secondbit.org/auth/rev/fc68085eb40d http://code.secondbit.org/auth/rev/fc68085eb40d changeset fc68085eb40d branch bookmark tag user Paddy <paddy@secondbit.org> description Add kubernetes definitions.

Define a replication controller that will spin up authd servers (using Ducky
right now--other instances should rename the ducky parts appropriately).

Also, my understanding of which labels go where may be shaky, which is probably
evidenced by the fact that all of these things share the same lables.

_Whatever_.

It also hooks the generated pods up to the JWT secret volume, so they can
properly read the JWT secret.

Also, created a LoadBalancer Service that will route traffic to the pods created
by the Replication Controller. files replication-controllers/authd.json
services/authd.json
]]> Paddy <paddy@secondbit.org> Mon, 29 Jun 2015 23:58:05 -0400 http://code.secondbit.org/auth/rev/aa14e29b666f http://code.secondbit.org/auth/rev/aa14e29b666f changeset aa14e29b666f branch bookmark tag user Paddy <paddy@secondbit.org> description Create Docker image for authd.

Create a Dockerfile for authd, which will wrap the compiled Go binary up into a
tiny little Docker image.

Create an authd/build-docker.sh script that will build the statically-linked
binary in a Docker container, so the authd Docker image can use it.

We had to include ca-certificates.crt in the Dockerfile, as well, so we could
communicate over SSL with things.

A wrapper.sh file is included that will pull the JWT_SECRET environment variable
out of a kubernetes secrets file, which is a handy wrapper to have.

Finally, we added the authd/docker-authd binary to the .hgignore. files .hgignore
authd/Dockerfile
authd/build-docker.sh
authd/ca-certificates.crt
authd/wrapper.sh
]]> Paddy <paddy@secondbit.org> Mon, 29 Jun 2015 23:50:15 -0400 http://code.secondbit.org/auth/rev/9e3ceddf29ad http://code.secondbit.org/auth/rev/9e3ceddf29ad changeset 9e3ceddf29ad branch bookmark tag user Paddy <paddy@secondbit.org> description Use an environment variable to set the JWT secret.

When setting up the authd server, populate the JWT secret using a JWT_SECRET
environment variable.

Incidentally, we also included the subscriptions scope, for testing purposes
while creating code.secondbit.org/ducky/subscriptions.

We now also log the port we're listening on, listen on all interfaces (instead
of just 127.0.0.1), and changed the port to 9000 instead of 8080. files authd/server.go
]]> Paddy <paddy@secondbit.org> Mon, 29 Jun 2015 23:30:29 -0400 http://code.secondbit.org/auth/rev/b0d1b3e39fc8 http://code.secondbit.org/auth/rev/b0d1b3e39fc8 changeset b0d1b3e39fc8 branch bookmark tag user Paddy <paddy@secondbit.org> description Make client use our auth(n/z) scheme.

Our auth(n/z) scheme can be loosely defined as "encrypted tokens that nginx
transforms into headers" and "scopes for bypassing ACL". Our Go client, which is
what we'll be using to have services communicate with each other, follows this
paradigm now by auto-injecting the headers we'll need to identify ourselves.
This will work behind our firewall, but will be useless for the rest of the
world, which will need to go through the nginx bastion that can strip the
headers and replace them with the headers appropriate to the token attached to
the request.

This did involve setting a static client ID as the client for our
email_verification listener. Ideally, this would cause Client registration
(using that ID) when the listener starts up, ignoring ErrClientAlreadyExists. I
don't want to have to write the code that will allow us to bypass the Client ACL
properly right now, though, so we're just going to have to remember to manually
create that Client. Or not. I don't think it will do any harm (outside the OAuth
flow) to be using a Client ID that doesn't actually point to a Client. I just
think it'd be good for record-keeping purposes. files authd/server.go
client/client.go
client/login.go
listeners/email_verification/listener.go
profile.go
]]> Paddy <paddy@secondbit.org> Sun, 17 May 2015 03:21:17 -0400