[Web-SIG] Standardized configuration

[Shannon -jj Behrens]

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. :-/

Oh well,
-jj

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.