Open Stack

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>