[Web-SIG] Communicating authenticated user information

[Clark C. Evans]

I'm using paste.auth.* modules, and they fill-in environ['REMOTE_USER']
with the authenticated user.  I then use this information in later
processing stages and it works nicely for me and is quite simple.

On Sun, Jan 22, 2006 at 03:24:52PM -0600, Ian Bicking wrote:
| So if the WSGI environ that the middleware sees initially is the same 
| environ that the authenticator writes too, then the middleware will
| see that change on the way out and include it.

For this case, I would imagine that a good transaction logger 
would come *before* the authentication middleware, stuffing away 
the ``environ`` and then hook into the ``start_response()`` callback 
to actually log the transaction (including the ``REMOTE_USER``) when
the response is created.  I don't see how a header would help here.

| Using a header would solve the problem where the environment is 
| completely changed (unlikely), or copied before REMOTE_USER is 
| assigned (fairly likely).

Ok.  If you are "completely changing" the environment, you should
just copy it and sent the copy on, so let us address these two cases
together.  In this situation, you also have to assume that the
authentication middleware happens *after* the request re-write or
you're in the situation described above (the logger can get the
REMOTE_USER).  I can picture two use-cases for this situation:

  Your server is doing a "internal redirect" to a sub-application
  that needs its own authentication.  In this case, why not just
  do an external redirect?

  Your server is doing N sub-requests, some of which require their
  own authentication, and assembling the results into a single
  response.  In this case, you'll need your own custom logging
  mechanism anyway... and I cannot imagine the complexity of 
  having N sub-branches that might return a 401.

In short, I can't think of any generic use-cases for this second
scenerio (where authentication happens *after* a complete re-write
of the environ) that would work with a generic request logging;
and I don't see how a header would help.

Perhaps I'm missing something?

Best,

Clark