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

Clark C. Evans cce at clarkevans.com
Thu Jan 26 02:43:04 CET 2006

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:


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:

        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.



More information about the Web-SIG mailing list