Open Stack

On 11/14/2012 01:47 PM, Kevin L. Mitchell wrote:
> On Wed, 2012-11-14 at 17:33 +0000, Yee, Guang wrote:
>> Yes WSGI pipeline. How else are you intend to use auth_token middleware?
>>
>> Looking at the changes
>>
>> https://review.openstack.org/#/c/16002/1/keystoneclient/middleware/auth_token.py
>>
>> You are basically setting the extensions data in the headers right?
>> You should be able to sanitize the X_<USER|TENANT|TOKEN>_EXTENSION
>> headers in header_sanitizer and set them in your own extension context
>> builder. What am I missing?
> I have gotten somewhat confused.  16002 is my review and was the
> approach I was shooting for, but heckj pushed back on that and brought
> it to the list to see if there were suggestions on other possible
> implementations; I had thought his suggested implementation was to
> subclass the auth_token middleware and try to solve my problem that way.
>
> If we like 16002, I'm quite happy with that approach; I can do
> everything I need to do by just implementing one more piece of
> middleware.  If that's not a desirable approach, I can suggest that we
> stuff the entire token validation response into the wsgi environment
> (not a header), which would also meet my needs.  If we want to use a
> subclassing approach, we need some further modification to the existing
> auth_token middleware to make that work, but that basically amounts to
> some refactoring, and I should again be able to make that work.  I just
> need to know which approach we are going to end up taking in the end :)
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.