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 has the same short-coming;
it does seem that using response headers is the only sane way to go
about solving this problem.
| That means you can't distribute the magic over xml-rpc or SOAP
| or some other protocol, and you might want to do that if you're
| using a load balancing feature or want part of the system
| to run as a different user.
In other words, each WSGI component in a stack should, ideally, not be
dependent upon mutable objects and should only use values that can be
passed by value. It's additional work; but I'll buy that one -- I just
don't buy the idea that extension APIs are superior to just requring the
``environ`` be constant through a given request.
This seems to be where Phillip is headed:
On Tue, Jan 24, 2006 at 11:37:30PM -0500, Phillip J. Eby wrote:
| WSGI is designed for functional composability. Requiring
| environ passthrough breaks that by creating a global coupling.
| If anything, in a 2.x WSGI version I would lean towards getting
| rid of extension APIs and replacing them with some kind of
| additional response facility, as it's still too easy to create
| global coupling or to bypass middleware via extension APIs.
On Tue, Jan 24, 2006 at 11:37:30PM -0500, Phillip J. Eby wrote:
| I don't see why an extension API placed in the environ, such as
| "paste.auth.set_user" doesn't satisfy this use case.
I must not have explained the modules clear enough; sorry for the
repetition, but let me take another stab at it.
I have several authentication modules, one for HTML form authentication,
basic, digest, and quite a few others. The function of these modules is
to ensure that environ['REMOTE_USER'] exists. If a remote user is
already provided, they are a no-op. Otherwise, they do what is
necessary (a 401, 302, returning an HTML form, etc.) in order to
get a remote user and fill in the environ.
Then I have a class of restoration modules, one which uses a signed key,
and another one that does path re-writing. These modules look to see if
they have enough information to fill in a REMOTE_USER, if not, they are
a no-op on the way in. On the way out, however, they *look* at the
``environ`` to see if REMOTE_USER was set -- if it was set they do
what ever they need to *save* this information.
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.
| You lost me. How does it do that in any way that the 'REMOTE_USER'
| variable does not?
Let's talk about both sorts of modules independently. First, the CGI
variable 'REMOTE_USER' is already well documented; and the goal of the
authentication modules is simple -- fill in that environment variable.
Your approach requires that an additional activity/burden is imposed on
these sorts of modules.
I agree that the cookie module isn't quite as straight-forward, but
it isn't that bad. Since the authentication modules are already
filling in the 'REMOTE_USER' to meet the expectations of standard
software components, it makes sense to obtain that inforamtion
directly from the environment.
In summary, I think extension APIs are more brittle and are a
poor substitute for just using a shared environ both up and
down the WSGI stack.
| >So, I reject this approach, and I suggested that the same ``environ``
| >object should be passed all the way down the WSGI stack.
|
| And as I've already said, this simply isn't possible in WSGI 1.x, as
| it's not backward compatible. That needs to be a 2.x revision, if it
| happens at all.
The WSGI middleware components that actually create their own environ
are few and far between. This is an uncommon edge case.
| >Ian presented 2 use cases in paste where a different environ
| >is passed down the stack, however, both of his cases can be fixed (as I
| >demonstrated) to be compliant with the suggested wording above.
|
| So we can make it harder for people to write middleware, in order to
| make it easier for people to introduce global coupling? That doesn't
| sound like a useful tradeoff -- certainly not one that overcomes the
| cost of changing the spec.
The change needed is trivial and minor compared to most other things you
have to get correct while writing WSGI middleware; and given the
relative immaturity of WSGI at this point (especially in edge cases like
this), I doubt it is the problem that you make it out to be.
In summary; I think that a response-headers approach as proposed by
Phillip is the best (but higher overhead) approach. However, I disagree
that some sort of extension API is preferable to just keeping the
``environ`` constant throughout the request.
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
