Uncle! Uncle!
On Wed, Jan 25, 2006 at 12:17:29PM -0500, Phillip J. Eby wrote:
| If each middleware or application does this:
|
| remote_user = environ.setdefault('paste.remote_user', [])
|
| And then uses the contents of that list as the thing to check or modify,
| then you will get the exa
At 01:53 AM 1/25/2006 -0500, Clark C. Evans wrote:
>Hence, the interfaces between these modules is simply using the
>well-understood CGI variable ``REMOTE_USER``. They can be used
>independently of each other, and in creative combinations.
If each middleware or application does this:
remote
Michal Wallace wrote:
> On Tue, 24 Jan 2006, Jim Fulton wrote:
>
>
>>Michal Wallace wrote:
>>
>>
>>>Maybe I just don't understand why this is important. Can someone (Jim)
>>>explain why this
>>>is a requirement in the first place?
>>
>>We do our own authentication for lots of reasons, including:
On Wed, Jan 25, 2006 at 12:41:01AM -0500, Michal Wallace wrote:
| Unfortunately, if you require it to be the exact same
| *object* then you're making the requirement that
| everything in the stack happens in the same process,
| on the same machine.
Correct. Phillip's extension APIs approach h
On Tue, 24 Jan 2006, Clark C. Evans wrote:
> On Mon, Jan 23, 2006 at 02:25:35PM -0500, Phillip J. Eby wrote:
> | You simply can't use environ values to communicate *up*
> | the WSGI stack, since at no level is it guaranteed you
> | have the "same" dictionary. Response headers and
At 09:42 PM 1/24/2006 -0500, Clark C. Evans wrote:
>Nice sermon; now can we get back to the issue being discussed without
>being argumentative and santimonious?
I didn't notice anyone being either of those. As for the sermon, however,
I'm glad you enjoyed it. :)
>Another use case for passing
On Tue, Jan 24, 2006 at 05:34:19PM -0500, Phillip J. Eby wrote:
| By turning that narrowly-stated issue into a general problem, you're
| dissolving three dimensions of specificity at once: i.e., you're turning
| the problem into essentially "communicating something about anything to
| anybody",
On Tue, 24 Jan 2006, Jim Fulton wrote:
> Michal Wallace wrote:
>
> > Maybe I just don't understand why this is important. Can someone (Jim)
> > explain why this
> > is a requirement in the first place?
>
> We do our own authentication for lots of reasons, including:
...
> History has shown us th
Michal Wallace wrote:
> On Tue, 24 Jan 2006, Jim Fulton wrote:
>
...
> Maybe I just don't understand why this is
> important. Can someone (Jim) explain why this
> is a requirement in the first place?
We do our own authentication for lots of reasons, including:
- Zope can provide user and group
At 01:55 PM 1/24/2006 -0500, Clark C. Evans wrote:
>On Tue, Jan 24, 2006 at 11:33:56AM -0500, Phillip J. Eby wrote:
>| > I think this is way too specific; it doesn't address the general
>| > problem: how do you pass information back up the middleware stack.
>
>| There is no "general problem" which
At 12:35 PM 1/24/2006 -0500, Michal Wallace wrote:
>Maybe I just don't understand why this is
>important. Can someone (Jim) explain why this
>is a requirement in the first place?
I'd like to know too, although the obvious argument is backward
compatibility for people accustomed to ZServer as Zope
web-sig@python.org
Subject: Re: [Web-SIG] Communicating authenticated user information
On Tue, 24 Jan 2006, Jim Fulton wrote:
> Phillip J. Eby wrote:
> ...
> > I'm pointing out that the use case under consideration isn't specific
> > *enough* yet. Do people's lo
On Tue, Jan 24, 2006 at 11:33:56AM -0500, Phillip J. Eby wrote:
| > I think this is way too specific; it doesn't address the general
| > problem: how do you pass information back up the middleware stack.
| There is no "general problem" which anyone is trying to solve. The use
| case requested by
On Tue, 24 Jan 2006, Jim Fulton wrote:
> Phillip J. Eby wrote:
> ...
> > I'm pointing out that the use case under consideration isn't specific
> > *enough* yet. Do people's log files support unicode? Do the
> > authentication systems? This hasn't been made clear, and it should be.
>
> I agree
Jim Fulton wrote:
> Phillip J. Eby wrote:
> ...
>
>>I'm pointing out that the use case under consideration isn't specific
>>*enough* yet. Do people's log files support unicode? Do the
>>authentication systems? This hasn't been made clear, and it should be.
>
>
> I agree. I think we should
At 10:30 PM 1/23/2006 -0500, Clark C. Evans wrote:
>Suggested Wording:
>
>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.
-1. This invalidates current WSGI
Phillip J. Eby wrote:
...
> I'm pointing out that the use case under consideration isn't specific
> *enough* yet. Do people's log files support unicode? Do the
> authentication systems? This hasn't been made clear, and it should be.
I agree. I think we should be guided by the common log file
At 10:15 PM 1/23/2006 -0500, Clark C. Evans wrote:
>On Mon, Jan 23, 2006 at 04:15:06PM -0500, Phillip J. Eby wrote:
>| At 03:36 PM 1/23/2006 -0500, Stephan Richter wrote:
>| > Specify a new environment variable called 'wsgi.user' (or something
>| > similar) that is a mutable and can be written seve
On Monday 23 January 2006 22:15, Clark C. Evans wrote:
> On Mon, Jan 23, 2006 at 04:15:06PM -0500, Phillip J. Eby wrote:
> | At 03:36 PM 1/23/2006 -0500, Stephan Richter wrote:
> | > Specify a new environment variable called 'wsgi.user' (or something
> | > similar) that is a mutable and can be writ
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 retr
On Mon, Jan 23, 2006 at 04:15:06PM -0500, Phillip J. Eby wrote:
| At 03:36 PM 1/23/2006 -0500, Stephan Richter wrote:
| > Specify a new environment variable called 'wsgi.user' (or something
| > similar) that is a mutable and can be written several times. Only
| > the last write (before the output
Clark C. Evans wrote:
> Thanks Phillip!
>
> This clears it up for me. Although, I disagree with the
> specification in this case; there does not seem to be a
> reason why middleware shouldn't be required to send the
> *same* environ dict along in subsequent calls.
Paste already does this, for
On Monday 23 January 2006 16:15, Phillip J. Eby wrote:
> I'd suggest a callable under 'wsgi.log_username', that takes one argument.
Sounds good to me.
> It should be specified whether it requires ASCII or Unicode.
I don't care; I think ASCII is fine; we can have the application handle the
encod
At 03:36 PM 1/23/2006 -0500, Stephan Richter wrote:
>Specify a new environment variable called 'wsgi.user' (or something similar)
>that is a mutable and can be written several times. Only the last write
>(before the output is sent) is important. By default the variable is set to
>``None`` for not s
On Monday 23 January 2006 15:12, Clark C. Evans wrote:
> Regardless of my opinion on the matter, what *is* being
> proposed for this particular problem; and more generally
> for these sorts of situations?
I think the following is being proposed (and also my favorite solution):
Specify a new envir
Thanks Phillip!
This clears it up for me. Although, I disagree with the
specification in this case; there does not seem to be a
reason why middleware shouldn't be required to send the
*same* environ dict along in subsequent calls.
Certainly a middleware component may make N sub-requests
to su
At 02:52 PM 1/23/2006 -0500, Clark C. Evans wrote:
>On Mon, Jan 23, 2006 at 02:25:35PM -0500, Phillip J. Eby wrote:
>| You simply can't use environ values to communicate *up* the WSGI stack,
>| since at no level is it guaranteed you have the "same"
>| dictionary.
>
>The same could be said for respo
On Monday 23 January 2006 14:25, Phillip J. Eby wrote:
> In the case of authentication, it should be sufficient to have a callable
> or mutable in the environ that can be called or set more than once per
> request, i.e. it only takes effect once the request is completed. This
> allows outer middle
On Mon, Jan 23, 2006 at 02:25:35PM -0500, Phillip J. Eby wrote:
| You simply can't use environ values to communicate *up* the WSGI stack,
| since at no level is it guaranteed you have the "same"
| dictionary.
The same could be said for response headers, no? You've got a WSGI
stack of A, B, and
At 12:42 PM 1/23/2006 -0500, Clark C. Evans wrote:
>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.
>
>Perh
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 th
On Sunday 22 January 2006 11:34, Phillip J. Eby wrote:
> >Is Zope the only WSGI application that performs authentication
> >itself?
>
> I think Zope is the only WSGI application that cares about communicating
> this information back to the web server's logs. :) Or at least, the only
> one whose a
Ian Bicking wrote:
> Jim Fulton wrote:
>
>> Typically, web servers provide access logs that include a label
>> for the authenticated user.
>>
>> Often, WSGI applications (or middleware) provide their own user
>> authentication facilities. Well, Zope does. :)
>>
>> There doesn't seem to be a stand
Jim Fulton wrote:
> Typically, web servers provide access logs that include a label
> for the authenticated user.
>
> Often, WSGI applications (or middleware) provide their own user
> authentication facilities. Well, Zope does. :)
>
> There doesn't seem to be a standard way for WSGI applications
[Alan Kennedy]
>> I agree about not sending this information back to the user: it's
>> unnecessary and potentially dangerous.
[Phillip J. Eby]
> Yep, it would be really dangerous to let me know who I just logged in to
> an application as. I might find out who I really am! ;)
Very droll ;-)
Wha
Phillip J. Eby wrote:
> At 05:45 PM 1/22/2006 +, Alan Kennedy wrote:
>
>>I agree about not sending this information back to the user: it's
>>unnecessary and potentially dangerous.
>
>
> Yep, it would be really dangerous to let me know who I just logged in to an
> application as. I might fi
At 05:45 PM 1/22/2006 +, Alan Kennedy wrote:
>I agree about not sending this information back to the user: it's
>unnecessary and potentially dangerous.
Yep, it would be really dangerous to let me know who I just logged in to an
application as. I might find out who I really am! ;)
__
[Jim Fulton]
>>>Is Zope the only WSGI application that performs authentication
>>>itself?
[Phillip J. Eby]
>>I think Zope is the only WSGI application that cares about
>> communicating this information back to the web server's logs. :)
[Jim Fulton]
> I hope that's not true. Certainly, if a
Phillip J. Eby wrote:
> At 11:22 AM 1/22/2006 -0500, Jim Fulton wrote:
>
>> Typically, web servers provide access logs that include a label
>> for the authenticated user.
>>
>> Often, WSGI applications (or middleware) provide their own user
>> authentication facilities. Well, Zope does. :)
>>
>>
At 11:22 AM 1/22/2006 -0500, Jim Fulton wrote:
>Typically, web servers provide access logs that include a label
>for the authenticated user.
>
>Often, WSGI applications (or middleware) provide their own user
>authentication facilities. Well, Zope does. :)
>
>There doesn't seem to be a standard way
Typically, web servers provide access logs that include a label
for the authenticated user.
Often, WSGI applications (or middleware) provide their own user
authentication facilities. Well, Zope does. :)
There doesn't seem to be a standard way for WSGI applications or
middleware to communicate th
41 matches
Mail list logo
