[Web-SIG] Standardized configuration
Shannon -jj Behrens
jjinux at gmail.com
Tue Jul 19 19:46:25 CEST 2005
It seems to me that authentication and authorization should be a put
into a library that isn't bound to the Web at all. I thought that
those guys reimplementing J2EE in Python did that. :-/
On 7/16/05, Chris McDonough <chrism at plope.com> 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.
> 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.
> 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.
> 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. 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.
> > Lately I've been thinking about the role of Paste and WSGI and
> > whatnot. Much of what makes a Paste component Pastey is
> > configuration; otherwise the bits are just independent pieces of
> > middleware, WSGI applications, etc. So, potentially if we can agree
> > on configuration, we can start using each other's middleware more
> > usefully.
> > I think we should avoid questions of configuration file syntax for
> > now. Lets instead simply consider configuration consumers. A
> > standard would consist of:
> > * A WSGI environment key (e.g., 'webapp01.config')
> > * A standard for what goes in that key (e.g., a dictionary object)
> > * A reference implementation of the middleware
> > * Maybe a non-WSGI-environment way to access the configuration (like
> > paste.CONFIG, which is a global object that dispatches to per-request
> > configuration objects) -- in practice this is really really useful, as
> > you don't have to pass the configuration object around.
> > There's some other things we have to consider, as configuration syntaxes
> > do effect the configuration objects significantly. So, the standard for
> > what goes in the key has to take into consideration some possible
> > configuration syntaxes.
> > The obvious starting place is a dictionary-like object. I would suggest
> > that the keys should be valid Python identifiers. Not all syntaxes
> > require this, but some do. This restriction simply means that
> > configuration consumers should try to consume Python identifiers.
> > There's also a question about name conflicts (two consumers that are
> > looking for the same key), and whether nested configuration should be
> > preferred, and in what style.
> > Note that the standard we decide on here doesn't have to be the only way
> > the object can be accessed. For instance, you could make your
> > configuration available through 'myframework.config', and create a
> > compliant wrapper that lives in 'webapp01.config', perhaps even doing
> > different kinds of mapping to fix convention differences.
> > There's also a question about what types of objects we can expect in the
> > configuration. Some input styles (e.g., INI and command line) only
> > produce strings. I think consumers should treat strings (or maybe a
> > special string subclass) specially, performing conversions as necessary
> > (e.g., 'yes'->True).
> > Thoughts?
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/jjinux%40gmail.com
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.
More information about the Web-SIG