[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