[mod_python] lookup_uri

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graham Dumpleton wrote:
> Note though that if using Apache properly, none of the above should be
> in handler() in the first place and should be in the authenhandler or
> authzhandlers phases instead.

Thank you for the reminder!

> And I did appreciate you might be doing that, but for the most obvious
> cases, at that time I couldn't see the point. If you are going to do
> that why not let Apache do all the authentication without this fiddle
> and have the AuthType/AuthName/Require directives on /admin in the
> first place since it is achieving exactly the same thing.

The rest api looks like this:

<Location /api/v1/widget><Limit GET> ... require stuff
<Location /api/v1/widget><Limit PUT DELETE POST> ... require stuff
<Location /api/v1/foo><Limit GET> ... require stuff
<Location /api/v1/foo><Limit PUT DELETE POST> ... require stuff
<Location /api/v1/bar><Limit GET> ... require stuff
<Location /api/v1/bar><Limit PUT DELETE POST> ... require stuff

ie the administrator can decide who can do what to which object.  They
have all the relevant apache modules at their disposal including things
like IP address based control.

For /admin I have a web based admin interface and want to generate a
page.  For the sake of argument, lets say that to generate a page I need
to GET a widget and DELETE a foo.  Using subrequests I can actually do
that and relevant requests get denied base on the access control rules
above.

It it is pretty much impossible to duplicate that fine grained access
control on the /admin location.  Instead I'd have to settle for access
or no access.

> This is where what you were doing seemed to be getting messy for my
> personal tastes in what simply appeared to be an attempt to avoid
> duplicating some auth configuration in the Apache configuration files.

I'd be happy duplicating if that were even possible!  Because the /admin
performs composite actions, it can't be done.

> If your /admin page needs to
> check more than one then you are simply probably getting beyond what
> the authorization directives of Apache are good for. 

As far as I can tell subrequests would do the job perfectly.  This link
even describes exactly what I want to use them for!

http://perl.apache.org/docs/1.0/api/Apache.html#Sub_Requests

"Apache provides a sub-request mechanism to lookup a uri or filename,
performing all access checks, etc., without actually running the
response phase of the given request."

> You can only go
> so far with what Apache directives give you. You may be better off
> just doing it all in your own authenhandler and authzhandlers for
> mod_python, you certainly shouldn't be trying to put authentication
> and authorisation into the response handler phase as you are.

Yes, you are right that authentication stuff should be generated and
processed in the appropriate phase :-)

> And I'd probably agree on that last point as mod_python falls quite
> short of being a true way of writing Apache modules but using Python
> instead of C code

Fortunately I am using such a trivial amount of mod_python that my own C
code apache module to call my own Python code isn't too onerous.

> The only practical way of getting a complete Python binding for Apache
> and APR C interfaces is to completely start over and use SWIG. 

It looked like modperl used SWIG so in theory their .i file could be
swiped as a starting point.

> Even then it is mostly useless in the context of mod_python
> anyway and a whole new base level module for doing Python in Apache is
> needed to support it. At this point there hasn't really been anyone
> else seriously interested in going that path, at least not to extent
> they appeared to be prepared to spend a great deal of time themselves
> working on it.

Have you tried asking the Perl folks since they are already maintaining
a swig'ed interface.  It may not be that much incremental work to add
python.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGSKT2mOOfHg372QQRAkF8AJ4j9dqlgH5vvqdDBcvz1sgPy0JdSQCg4yAq
vdezCavW6WqceBlUKs8URzk=
=PIhM
-----END PGP SIGNATURE-----