PythonFixupHandler Equivalent
Jason Davies
Is there an equivalent to PythonFixupHandler for mod_wsgi? I'm
switching to mod_wsgi from mod_python, and I have a couple of "fixup
handlers", which I use to add custom request headers to the request
before it gets passed on to something else. The something else can
either be a PHP script or a Python webapp.
Thanks,
Jason
Graham Dumpleton
The ability to write low level handlers directly like that is not
likely to happen. There are sort of ways around this though.
Can you provide an example of what you are doing and perhaps explain
why something like mod_headers is insufficient?
Graham
Jason Davies
wrote:
> On 15/01/2008, Jason Davies <jason.dav...@gmail.com> wrote:
> > Is there an equivalent to PythonFixupHandler for mod_wsgi? I'm
> > switching to mod_wsgi from mod_python, and I have a couple of "fixup
> > handlers", which I use to add custom request headers to the request
> > before it gets passed on to something else. The something else can
> > either be a PHP script or a Python webapp.
>
> The ability to write low level handlers directly like that is not
> likely to happen. There are sort of ways around this though.
>
> Can you provide an example of what you are doing and perhaps explain
> why something like mod_headers is insufficient?
kind of filtering/wrapping mechanism, which intercepts the request and
ensures that the client is logged in, either via HTTP auth or via
session-based (cookies) auth. If the client is not logged in, then it
is either prompted for HTTP auth credentials, or it is redirected to a
login page.
The authentication is hooked into Django's auth framework, so ideally
I want to be able to write these filters in Python (hence mod_headers
isn't really much use here). However, the resources being protected
are not necessarily Python-based, they could be static files, PHP, or
even Subversion (over WebDAV).
I have written several fixup handlers for use with mod_python to
tackle this. They can be chained together, and if a client is logged
in, the client's user id is passed to the resource via a special X-
User-Id header in the request.
Any alternative ideas would be welcomed.
Regards,
Jason
Brian Smith
> ideally I want to be able to write these filters in Python
> (hence mod_headers isn't really much use here). However, the
> resources being protected are not necessarily Python-based,
> they could be static files, PHP, or even Subversion (over WebDAV).
http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms
Jason Davies
> > The authentication is hooked into Django's auth framework, so
> > ideally I want to be able to write these filters in Python
> > (hence mod_headers isn't really much use here). However, the
> > resources being protected are not necessarily Python-based,
> > they could be static files, PHP, or even Subversion (over WebDAV).
>
> http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms
examine some Django session data and verify that a user is logged in
based on that, and issue a redirect to '/accounts/login/' if they
aren't.
It could be that I'm asking too much, and I should just perform these
checks in the applications themselves, whether they are PHP or
whatever. However, it would be nice to only write the checks once and
keep them all in one module that would protect several resources.
Regards,
Jason
Brian Smith
> On Jan 16, 12:36 am, "Brian Smith" <br...@briansmith.org> wrote:
> > > The authentication is hooked into Django's auth framework, so
> > > ideally I want to be able to write these filters in Python (hence
> > > mod_headers isn't really much use here). However, the resources
> > > being protected are not necessarily Python-based, they could be
> > > static files, PHP, or even Subversion (over WebDAV).
> >
> > http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms
>
> That's useful for HTTP auth, but it's not clear how I would
> be able to examine some Django session data and verify that a
> user is logged in based on that, and issue a redirect to
> '/accounts/login/' if they aren't.
My understanding is that all DJango session state is stored in the
database, so it should be simultaneously accessible to the
authentication handler and the Django applications; it is just a matter
of configuring Django to share the session state between the two
applications. I don't know how to do it with DJango, but I imagine that
it is done the same way all other multiprocess configuration is done for
Django. See:
http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
"If any area of Django does give problems it may be its
support for sessions. This is because Django does not implement
any form of global session locking. That this is lacking though
should by rights also cause problems with multi process server
configurations as well as multithreaded servers."
http://code.djangoproject.com/ticket/1180
http://code.djangoproject.com/ticket/4531
> It could be that I'm asking too much, and I should just
> perform these checks in the applications themselves, whether
> they are PHP or whatever. However, it would be nice to only
> write the checks once and keep them all in one module that
> would protect several resources.
If you can find a way to get to get the session state sharing to work,
like above, then I think there is no problem. But, I think more a more
elaborate auth provider framework is too far out of scope for a WSGI
gateway. Graham has said that he would like mod_wsgi to become a kind of
Apache-WSGI fusion framework, so he probably disagrees. Perhaps, in
mod_wsgi 3.0, it will be possible to break out the core "pure WSGI"
functionality into a module seperate from the Apache-centric features.
- Brian
Jason Davies
On Jan 16, 1:20 am, "Brian Smith" <br...@briansmith.org> wrote:
> > >http://code.google.com/p/modwsgi/wiki/AccessControlMechanisms
>
> > That's useful for HTTP auth, but it's not clear how I would
> > be able to examine some Django session data and verify that a
> > user is logged in based on that, and issue a redirect to
> > '/accounts/login/' if they aren't.
>
> My understanding is that all DJango session state is stored in the
> database, so it should be simultaneously accessible to the
> authentication handler and the Django applications; it is just a matter
> of configuring Django to share the session state between the two
> applications. I don't know how to do it with DJango, but I imagine that
> it is done the same way all other multiprocess configuration is done for
> Django. See:
>
> http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
> "If any area of Django does give problems it may be its
> support for sessions. This is because Django does not implement
> any form of global session locking. That this is lacking though
> should by rights also cause problems with multi process server
> configurations as well as multithreaded servers."
> http://code.djangoproject.com/ticket/1180
> http://code.djangoproject.com/ticket/4531
want clients to be able to login via methods other than HTTP auth
(Basic and Digest), e.g. cookie-based Django sessions. Correct me if
I'm wrong, but it seems I can only use HTTP auth with the mod_wsgi
auth handler at the moment.
Jason
gert
def application(environ, response):
sid = environ.get('HTTP_COOKIE','')
....
Brian Smith
> Sharing Django session state is relatively simple. My point
> is that I want clients to be able to login via methods other
> than HTTP auth (Basic and Digest), e.g. cookie-based Django
> sessions. Correct me if I'm wrong, but it seems I can only
> use HTTP auth with the mod_wsgi auth handler at the moment.
I see. You could probably use mod_headers to convert the cookie into an
"Authorization: DjangoCookie <cookie>" Authorization header, which would
presumably cause mod_wsgi to invoke your authentication script, which
can then parse the Authorization header to check for "Basic" vs
"DjangoCookie" and go from there.
- Brian
Graham Dumpleton
The problem is that once the Apache auth provider mechanism is
triggered the only option it provides is to allow access, or return
HTTP_UNAUTHORIZED. There is no way using an Apache auth provider to
trigger a redirect to some special page or return a different status.
A discussion was had on this of sorts against:
http://code.google.com/p/modwsgi/issues/detail?id=48&can=1
They didn't want cookie based sessions, but did want to change the
return status, albeit for authorisation and not authentication.
How auth providers and authorisation works is just how it works and it
is done in the same way that Apache does it. So, no real avenue for
trying to fudge things using it.
In the past I have thought about session based access controls across
disparate applications and static files and have implemented such
things for mod_python. These days I really don't know where this fits
into mod_wsgi since everyone seems more interested in just WSGI and
not the bigger picture of Apache as a web development platform. So,
some of my grander ideas seem to be falling by the way side.
There are probably going to be some big discussions in the coming
weeks on the list about where mod_wsgi goes after 2.0, so maybe hang
around, monitor that and speak up when we talk about what aspects of
what mod_python is capable of doing do we want to try and provide
equivalents for, or not as might be the case.
Graham
Graham Dumpleton
> Graham Dumpleton wrote:
> > The problem is that once the Apache auth provider mechanism
> > is triggered the only option it provides is to allow access,
> > or return HTTP_UNAUTHORIZED. There is no way using an Apache
> > auth provider to trigger a redirect to some special page or
> > return a different status.
> >
> > A discussion was had on this of sorts against:
> >
> > http://code.google.com/p/modwsgi/issues/detail?id=48&can=1
>
> looks like that has already been explored in the above issue.
Unfortunately not, as you cant use the error document to force a
different status such as redirection. Browsers will not generally even
show any custom 401 error document as their immediate action is to pop
up the password dialog again.
Graham