[Web-SIG] WSGI deployment use case

[Ian Bicking]

Well, the stack is really just an example, meant to be more realistic 
than "sample1" and "sample2".  I actually think it's a very reasonable 
example, but that's not really the point.  Presuming this stack, how 
would you configure it?


Chris McDonough wrote:
> 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).