[Web-SIG] Logging the authenticated user (was Re: Bowing out)
Phillip J. Eby
pje at telecommunity.com
Tue Feb 7 19:23:56 CET 2006
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.
>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.
More information about the Web-SIG