[Web-SIG] Standardized configuration
ianb at colorstudy.com
Sun Jul 17 06:29:46 CEST 2005
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
> 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
> 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
More information about the Web-SIG