[Web-SIG] Standardized configuration

[Ian Bicking]

Chris McDonough wrote:
> I've also been putting a bit of thought into middleware configuration,
> although maybe in a different direction.  I'm not too concerned yet
> about being able to introspect the configuration of an individual
> component.  Maybe that's because I haven't thought about the problem
> enough to be concerned about it.  In the meantime, though, I *am*
> concerned about being able to configure a middleware "pipeline" easily
> and have it work.

There's nothing in WSGI to facilitate introspection.  Sometimes that 
seems annoying, though I suspect lots of headaches are removed because 
of it, and I haven't found it to be a stopper yet.  The issue I'm 
interested in is just how to deliver configuration to middleware.

Because middleware can't be introspected (generally), this makes things 
like configuration schemas very hard to implement.  It all needs to be 
late-bound.

> I've been attempting to divine a declarative way to configure a pipeline
> of WSGI middleware components.  This is simple enough through code,
> except that at least in terms of how I'm attempting to factor my
> middleware, some components in the pipeline may have dependencies on
> other pipeline components.

At least in Paste, you just have to set up the stack properly.  It would 
be cool if middleware could detect the presence of its prerequesites, 
and add the prerequesites if they weren't present; I don't think that's 
terribly complicated, but I haven't actually tried it.  Mostly you'd 
test for a key, and if not present then you'd instantiate the middleware 
and reinvoke.

> For example, it would be useful in some circumstances to create separate
> WSGI components for user identification and user authorization.  The
> process of identification -- obtaining user credentials from a request
> -- and user authorization  -- ensuring that the user is who he says he
> is by comparing the credentials against a data source -- are really
> pretty much distinct operations.  There might also be a "challenge"
> component which forces a login dialog.

I've always thought that a 401 response is a good way of indicating 
that, but not everyone agrees.  (The idea being that the middleware 
catches the 401 and possibly translates it into a redirect or something.)

> In practice, I don't know if this is a truly useful separation of
> concerns that need to be implemented in terms of separate components in
> the middleware pipeline (I see that paste.login conflates them), it's
> just an example.  

Do you mean identification and authentication (you mention authorization 
above)?  I think authorization is different, and is conflated in 
paste.login, but I don't have any many use cases where it's a useful 
distinction.  I guess there's a number of ways of getting a username and 
password; and to some degree the  authenticator object works at that 
level of abstraction.  And there's a couple other ways of authenticating 
a user as well (public keys, IP address, etc).  I've generally used a 
"user manager" object for this kind of abstraction, with subclassing for 
different kinds of generality (e.g., the basic abstract class makes 
username/password logins simple, but a subclass can override that and 
authenticate based on anything in the request).

Maybe there's a better term, the fact these two words start with "auth" 
causes all kinds of confusion.  Conflating identification and 
authentication isn't so bad, but authentication and authorization is 
really bad (but common).

> But at very least it would keep each component simpler
> if the concerns were factored out into separate pieces.
> 
> But in the example I present, the "authentication" component depends
> entirely on the result of the "identification" component.  It would be
> simple enough to glom them together by using a distinct environment key
> for the identification component results and have the authentication
> component look for that key later in the middleware result chain, but
> then it feels like you might as well have written the whole process
> within one middleware component because the coupling is pretty strong.
> 
> I have a feeling that adapters fit in here somewhere, but I haven't
> really puzzled that out yet.  I'm sure this has been discussed somewhere
> in the lifetime of WSGI but I can't find much in this list's archives.

No, I don't think so.  It was something I experimented with in 
paste.login (purely intellectually, I haven't used it in a real app), 
and Aaron Lav did a little work on it as well, but until it gets some 
use it's hard to know how complete it is.

As long as it's properly partitioned, I don't think it's a terribly hard 
problem.  That is, with proper partitioning the pieces can be 
recombined, even if the implementations aren't general enough for all 
cases.  Apache and Zope 2 authentication being examples where the 
partitioning was done improperly.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org