[Web-SIG] WSGI deployment use case

[Chris McDonough]

Just for a frame of reference, I'll say how I might do these things.
These all assume I'd use Apache and mod_python, for better or worse:

> I'm not clear exactly what you are proposing.  Let's use a more 
> realistic example.  Components:
> 
> * Exception catcher.  Takes "email_errors", which is a list of addresses 
> to email exceptions to.  I want to apply this globally.

I'd likely do this in my endpoint apps (maybe share some sort of library
between them to do it).  Errors that occur in middleware would be
diagnosable/detectable via mod_python's error logging facility and
something like snort.

> * An application mounted on /, which takes "document_root" and serves up 
> those files directly.

Use the webserver.

> * An application mounted at /blog, takes "database" (a string) where all 
> its information is kept.

Separate WSGI pipeline descriptor with rewrite rules or whatever
aliasing "/blog" to it.

> * An application mounted at /admin.  Takes "document_root", which is 
> where the editable files are located.  Around it goes two pieces of 
> middleware...

Same as above...

> * A authentication middleware, which takes "database", which is where 
> user information is kept.  And...

I'd probably make this into a service that would be consumable by
applications with a completely separate configuration outside of any
deployment spec.  For example, I might try to pull Zope's "Pluggable
Authentication Utility" out of Zope 3, leaving intact its
configurability through ZCML.

But if I did put it in middleware, I'd put it in each of my application
pipelines (implied by /blog, /admin) in an appropriate place.

> * An authorization middleware, that takes "allowed_roles", and checks it 
> against what the authentication middleware puts in.

This one I know wouldn't make into middleware.  Instead, I'd use a
library much like the thing I proposed as "decsec" (although at the time
I wrote that proposal, I did think it would be middleware; I changed my
mind).

- C