[Web-SIG] Logging the authenticated user (was Re: Bowing out)

[Phillip J. Eby]

At 11:50 AM 2/7/2006 -0600, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>So, if there are no objections, I propose that we:
>>* Add an optional 'wsgi.response_filtering' key to the spec.  If its 
>>value is present and true, the server promises to prevent 'X-Internal-*' 
>>headers from being transmitted.
>>* Add an optional 'X-Internal-WSGI-Authenticated-User' header to the 
>>spec, that indicates the authenticated user name.  This should only be 
>>inserted into the response headers if 'wsgi.response_filtering' is in effect.
>>* Require that any user-defined X-Internal headers include a product 
>>name, e.g. 'X-Internal-Zope-Foo', to avoid conflict with WSGI-defined or 
>>other products' user-defined headers.
>>This would all be placed under a new section entitled "Internal Response 
>>Headers" and defined as an optional extension.
>>Any thoughts?
>
>Sounds good to me, and wsgi.response_filtering seems to address the 
>backward compatibility well.  It would be easy, for instance, to apply the 
>filtering in the logging middleware if the server was not already 
>filtering the response, and set the key to represent that the filtering 
>was in place.

This brings up an interesting point, which is to what extent middleware can 
or should filter internal headers it doesn't understand, and what kinds of 
functionality are acceptable to expose via response headers.  That issue 
deserves some more thought before the spec addition is made, although for 
this particular application I'm thinking that folks are probably safe 
prototyping based on just the info above.

The only issue remaining is whether there are any objecting parties.  I 
believe that Clark Evans eventually agreed that response headers were the 
best long-term way to address middleware composition issues in upward 
communication like this, but we should leave the proposed extension open to 
objections for a few days in any case.

And of course the issue of what's acceptable to expose via headers and 
what's acceptable for middleware to ignore or pass through is very much 
open for discussion, since it needs to be resolved before the actual spec 
can be written.