[Web-SIG] Communicating *up* the WSGI Stack

[Herb Lainchbury]

Sounds reasonable.

If you're going to provide a facility for passing stuff up (or sideways in
the case of multi-server feature), and if you're going to strip it off
before sending it to the web server, you might as well pickle/marshal a
whole object in which you can toss anything you want in.  

It's sort of like a global request storage area that lives only for the
current request.  The framework would be allowed to peek in and get the
userid if it's available.

Herb Lainchbury
Dynamic Solutions Inc.
www.dynamic-solutions.com

-----Original Message-----
From: web-sig-bounces+herb=dynamic-solutions.com at python.org
[mailto:web-sig-bounces+herb=dynamic-solutions.com at python.org] On Behalf Of
Clark C. Evans
Sent: Wednesday, January 25, 2006 5:43 PM
To: web-sig at python.org
Subject: [Web-SIG] Communicating *up* the WSGI Stack

In the recent discussion, "Communicating Authenticated User
Information", Jim Fulton asked for a standard way for WSGI
applications to communicate the authenticated user back to
the web server for logging purposes.   I have a related need
for signed cookies (including both the user and the session
identifier); and in some of my application development other
similar needs.

The current solution under consideration is a 'wsgi.set_user' 
callback that the application can call to inform up-stream
WSGI middleware components about the current user.  If we go
with an approach like this, I'd rather it be generalized via
something like 'wsgi.upstream(key, value)' which any WSGI
middlelayer could hook-into.

However, I'm much more intrigued by PJE's suggestion that we
use response headers, like 'X-Authenticated-User', rather
than adding an extension API for this feature.  This solution 
has the advantage that a 'WSGI' stack could be distributed
over multiple servers, as suggested by Michal Wallace.

Since I'm a generalist nut (a good or a bad thing), I was
thinking of a solution that would let me communicate session
identifiers, and other application specific information
up-stream to the logging service (and perhaps other
services).  I was wondering if this could be done in a more
general way, and took a quick stab at it:

   http://clarkevans.com/tmp/gateway-environment/spec.html

The goal of this sort of header is to allow just about any
CGI or other environment variable to be communicated *up* a
server stack in a response header (as well as down the stack
if distributing WSGI services over more than one server); 
in a way that would be stripped before the final response 
went out to the server.
 
With a header such as this, Jim's request could be addressed
(using a Russian user nick-named "sugar") as:

    Gateway-Environment:
        REMOTE_IDENT = "=?UTF-8?b?0YHQsNGF0LDRgA==?="

Any thoughts?  If this seems like a positive direction, I 
could work on a few helper tools to make it painless.

Best,

Clark
_______________________________________________
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/herb%40dynamic-solutions.com