[Web-SIG] Communicating authenticated user information
Clark C. Evans
cce at clarkevans.com
Tue Jan 24 04:30:53 CET 2006
I'm not convinced that we shouldn't just require WSGI middleware
to forward on the *exact* same ``environ`` as it receives.
On Mon, Jan 23, 2006 at 03:29:32PM -0600, Ian Bicking wrote:
| Paste already does this, for the N subrequest method. This is done at
| least in paste.cascade, where we retry the request several times until
| something responds with a non-404.
Yes; this is exactly the sort of edge cases that I think will elude just
about any "general" solution. How would Phillip's recent suggestion,
for example, a ``wsgi.log_username`` work in this situation?
If a WSGI middleware component _isn't_ passing on the actual
``environ`` given by its parent, then it is an edge case where
this problem can't be solved anyway.
| I suppose you could update the one-and-only environ from a copy
| you made before sending the request on. But anyway, it doesn't do that.
Yes, you could for this case _copy_ the ``environ`` and then when
one of the cascade applications returns, you can update the
original ``environ`` with the saved copy.
A WSGI Middleware component (that is, one that receives a
request and forwards it on to another component) must forward
on the *exact* same ``environ`` dict that it received.
| I'd like to do this same thing (N subrequests) sometime in the future
| for server-side HTML Overlays.
The above restriction won't hurt these use-cases (which you must
be careful about anyway), and it addresses the current issue:
how does one pass information back up the call chain.
More information about the Web-SIG