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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
