[openstack-dev] [KEYSTONE] subclassing auth_token middleware

Yee, Guang guang.yee at hp.com
Wed Nov 14 17:33:48 UTC 2012


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?


Guang



-----Original Message-----
From: Kevin L. Mitchell [mailto:kevin.mitchell at rackspace.com] 
Sent: Wednesday, November 14, 2012 9:07 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [KEYSTONE] subclassing auth_token middleware

On Wed, 2012-11-14 at 16:46 +0000, Yee, Guang wrote:
> Sure, we can have a generic header_sanitizer filter sitting in front
> of token_validator so the pipeline would look something like this

Are you talking about in the WSGI pipeline?  That wasn't exactly what I
was envisioning, and it wouldn't completely solve my problem.  If you're
just talking about the "pipeline" that is the sequence of calls in
__call__(), OTOH, that's fine; we just need to figure out the proper
interface.

> header_sanitizer: removes the given set of headers from the request.
> Headers to be removed are configured in the filter section.
> token_validator: does token caching (including cache encryption) if
> necessary; validates the token using a set of configurable protocols
> (i.e. http, https, pki, etc); and sets the raw token in the
> environment.

Well, again, this sounds like using the pipeline; and if you're setting
the raw token in the environment, well, that's essentially what my patch
does…

> context_builder: builds the default Keystone context from the raw
> token by setting the X_USER_ID, X_TENANT_ID headers, etc.
> <3rd party context builder>: additional header/environment
> manipulation

>From your description, these would end up being other pieces of
middleware, and this essentially matches the approach I was attempting
with my patch.

> We should have a "contrib" folder in python-keystoneclient to stash
> the 3rd party middlerware filters. When a 3rd party middleware filter
> becomes mainstream, we'll promote it to core/default in the next
> release.

Hrm.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121114/6c6a2ec8/attachment.bin>


More information about the OpenStack-dev mailing list