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

[Phillip J. Eby]

At 12:02 PM 2/7/2006 -0500, Stephan Richter wrote:
>BTW, did we reach a conclusion on the user logging issue. We really, really
>need to solve that somehow. Anything you can come up with is fine by me; I'll
>trust you do the right thing.

As I mentioned, you can do this right now by offering and documenting an 
extension API.  You don't need a modification to the PEP to do this; it's 
sufficient for you to get together with the authors of the web servers you 
care about and hash out a working agreement.

To get it into the 'wsgi.*' namespace and included in the PEP as a 
"standard" optional extension, the bar is a bit higher, and it does require 
coming to some resolution about the remaining issues.  If I recall 
correctly, the question of which side (server or app) should be responsible 
for encoding issues was the remaining open item, aside from the name that 
should be used for the extension API.

Also IIRC, Ian Bicking had proposed that the server should be responsible 
for making sure that what it writes to the log is in a valid format for 
that log.  I'm inclined to agree, and think we should use a name like 
'wsgi.set_authenticated_user_name', with the API allowed to be called 
multiple times.

For future versions of WSGI, I'd prefer to send this kind of thing in 
response headers, since that would preserve functional composability 
better.  Indeed, I'd prefer to do it that way now, but too many people have 
objected to this as a security risk.

OTOH, an easy way to fix that would be for us to define a 
'wsgi.response_filtering' key that means the server will drop any 
'X-Internal-Foo' headers.  You can then simply avoid generating any 
internal communication headers unless the server promises to fix 
them.  And, as a side effect, this would close the encoding issue by 
definition; the format of response headers is already dictated by the WSGI 
and HTTP specs.

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?