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