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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clark C. Evans Sent: Wednesday, January 25, 2006 5:43 PM To: web-sig@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@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/herb%40dynamic-solutions.com _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
