Open Stack

On Thu, 2012-11-15 at 09:56 -0500, Adam Young wrote:
> OK, if I understand correctly, there are two distinct issues getting 
> mixed here.
> 
> 1.  Handling tokens in HTTP environments.
> 2.  Extending the data that is carried in the Auth token signed document.
> 
> My gut feeling is that additional Headers is a mistake.  The payload of 
> the signed messages should be extracted only once, expanded, and added 
> to the WSGI context.  Anything that needs to consume the data downstream 
> should read it as Python objects, not as strings out of headers.  I 
> never really understood the rationale for additional custom headers from 
> validate.

The reason I chose the headers route, rather than the wsgi environment
route, was because of an original design goal of the auth_token
middleware.  In retrospect, it's not necessary for my change to have
been done the way I did, and placing the extracted token validation into
the wsgi environment makes sense.  However, in answer to your statement,
about custom headers, maybe it'd be worth mentioning the design goal, as
I understand it, of how auth_token was designed.

In short, the auth_token middleware was designed so that it could be run
from a proxy, rather than directly in the WSGI pipeline.  The idea was
to allow for a case where you have a reverse proxy, which performs the
authentication check, then forwards the HTTP request (with the added
authentication headers) on to the actual service running on another host
entirely.  In addition, using the headers allows for alternate
authentication implementations; as long as they set the same headers,
you can use any authentication backend you want.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>