As I asked before, send me the code for what the mod_python access handler does.
If I haven't already mentioned it, perhaps look at: http://www.openfusion.com.au/labs/mod_auth_tkt/ Graham On 22 October 2011 08:36, Forest <[email protected]> wrote: >> Try dumping out the contents of request.subprocess_env and see if >> there are any REDIRECT_? values you can check. > > I checked, and found no such values. > > The remaining workarounds are getting too complicated for my liking. > I guess I'll rearrange the site to avoid using *AliasMatch, or maybe > give up on MoinMoin. > > I'd get rid of mod_python if I could, but I need apache-openid (or > something like it). If there was an alternative to mod_python that > allowed an OpenID implementation in python (intercept arbitrary apache > requests, perform conditional redirects, etc.) I'd gladly port > apache-openid to it. Sadly, I don't think mod_wsgi's auth hooks are > enough to make this work. > > Thanks for all the suggestions, Graham. > > Cheers, > > Forest > > On Wed, Oct 12, 2011 at 14:10, Graham Dumpleton > <[email protected]> wrote: >> On 13 October 2011 04:49, Forest <[email protected]> wrote: >>> Thanks for all the suggestions, Graham. As you guessed, my apache >>> access handler runs under mod_python. (A requirement of apache-mod- >>> python.) I can modify it if it's misbehaving, of course. >>> >>> To that end, I've just spent some time playing with my mod_python >>> accesshandler, and found something interesting. The very first action >>> it takes is: "if request.main: return apache.DECLINED". The idea here >>> is to do nothing for sub-requests. When I remove that bit of code, >>> using WSGIScriptAliasMatch no longer triggers the recursion/segfault. >>> Odd. When I add a single line containing only "request.main" back into >>> the code, using WSGIScriptAliasMatch once again triggers the recursion/ >>> segfault. Looks like simply reading the value of "request.main" in a >>> mod_python access handler causes a crash when WSGIScriptAliasMatch is >>> in play. I'm pretty sure python code should be unable to crash the >>> interpreter or apache. Could this be a bug in mod_python, or possibly >>> in mod_wsgi? >> >> There are still lots of known documented bugs in mod_python and not >> surprised if request.main causes a problem. That specific ability was >> always dodgy and I remember making some fixes for it to avoid mixing >> Python objects across Python sub interpreters. Code could still be >> wrong of Apache has changed in the mean time to make it not work. >> >> You could try forcing: >> >> PythonInterpreter main >> >> and see if that helps. >> >>> (If so, I wonder if there's an alternative way for a >>> mod_python handler to detect a subrequest.) >> >> Try dumping out the contents of request.subprocess_env and see if >> there are any REDIRECT_? values you can check. >> >> If you had mod_rewrite available you could also do something like have >> a rule which checks for IS_SUBREQ and then set an ENV variable which >> can be checked. >> >> You might just send me the access handler code and I can think whether >> there is any way you could do it another way. >> >> Graham >> >>> Putting that issue aside for a moment, and leaving all "request.main" >>> references commented out in the mod_python access handler to avoid the >>> crash, I found that this syntax yields the SCRIPT_NAME and PATH_INFO >>> values I've been seeking: >>> >>> WSGIScriptAliasMatch ^/(?!auth|sitepage) /var/moin/apidoc/server/ >>> moin.wsgi >>> >>> This syntax started working as well: >>> >>> Alias /auth /path/to/apache-openid/stuff >>> Alias /sitepage /path/to/other/stuff >>> WSGIScriptAlias / /var/moin/apidoc/server/moin.wsgi >>> >>> In both cases, SCRIPT_NAME is always '' and PATH_INFO is the full path >>> from the requested URL. >>> >>> So, this is a lot of progress. I guess now I need to figure out why >>> WSGIScriptAliasMatch turns mod_python's request.main field into a land >>> mine that explodes when read. >>> >>> >>> On Oct 12, 2:18 am, Graham Dumpleton <[email protected]> >>> wrote: >>>> I do some looking at WSGIScriptAliasMatch, but can we go back to the >>>> original reason for doing this. >>>> >>>> What needs to be served up when access the URLs: >>>> >>>> /auth >>>> /sitepage >>>> >>>> Overlapping sets of URLs can be handled in various ways and AliasMatch >>>> directives should always be the last option. >>>> >>>> If you have: >>>> >>>> WSGIScriptAlias / /var/moin/apidoc/server/moin.wsgi >>>> >>>> and need a different WSGI application at the other URLs, you would use: >>>> >>>> WSGIScriptAlias /auth /some/path/auth.wsgi >>>> WSGIScriptAlias /sitepage /some/path/sitepage.wsgi >>>> >>>> WSGIScriptAlias / /var/moin/apidoc/server/moin.wsgi >>>> >>>> If the URLs are for static resources or dynamic scripts the handler of >>>> which is specified by AddHandler, then use Alias instead to override: >>>> >>>> Alias /auth /some/path/auth.cgi >>>> Alias /sitepage /some/path/sitepage.html >>>> >>>> WSGIScriptAlias / /var/moin/apidoc/server/moin.wsgi >>>> >>>> Another alternative is to do as described in: >>>> >>>> http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apa... >>>> >>>> and have appropriate config including: >>>> >>>> AddHandler wsgi-script .wsgi >>>> >>>> with rewrite rule of: >>>> >>>> RewriteEngine On >>>> RewriteCond %{REQUEST_FILENAME} !-f >>>> RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L] >>>> >>>> What happens here is that Apache files exact resource in directory it >>>> will use that, otherwise it falls back to pushing everything through >>>> site.wsgi application. >>>> >>>> So there are easier alternatives to using WSGIScriptAliasMatch or >>>> AliasMatch, but am unclear of what this python-apache-openid is. It >>>> sounds a bit like it might be dependent on mod_python which is asking >>>> for trouble. What is the configuration in the Apache configuration for >>>> that package and how is it triggered? >>>> >>>> Graham >>>> >>>> On 12 October 2011 19:09, Forest <[email protected]> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> > I did. (See below.) >>>> >>>> > On Oct 12, 1:06 am, Graham Dumpleton <[email protected]> >>>> > wrote: >>>> >> Did you try the same pattern I gave you for WSGIScriptAliasMatch with >>>> >> AliasMatch. Ie., no .* and the $1 substitution? >>>> >>>> >> Graham >>>> >>>> >> On 12 October 2011 18:00, Forest <[email protected]> wrote: >>>> >>>> >> > mod_rewrite isn't even enabled on this server. >>>> >>>> >> > I do have an access handler (Ubuntu's python-apache-openid) configured >>>> >> > in my <Directory /var/moin/apidoc/server> section. It's designed to >>>> >> > redirect to /auth/+login if a cookie isn't set, which is why I'm >>>> >> > excluding /auth in my AliasMatch regex. Removing the access handler >>>> >> > gets rid of the infinite subrequest / segfault when I use >>>> >> > WSGIScriptAliasMatch, but since AliasMatch works fine with the access >>>> >> > handler enabled, it didn't seem worth my time to debug >>>> >> > WSGIScriptAliasMatch. That's why I'm trying to get SCRIPT_NAME and >>>> >> > PATH_INFO to be set correctly when I use AliasMatch. >>>> >>>> >> > Of course, if you know how to get WSGIScriptAliasMatch to avoid the >>>> >> > segfault just as AliasMatch does, I guess that might work just as >>>> >> > well. >>>> >>>> >> > On Oct 11, 11:35 pm, Graham Dumpleton <[email protected]> >>>> >> > wrote: >>>> >> >> Do you have any separate mod_rewrite rules in your Apache >>>> >> >> configuration? >>>> >>>> >> >> WSGIScriptAliasMatch itself should not trigger any internal >>>> >> >> redirections that I know of. >>>> >>>> >> >> Graham >>>> >>>> >> >> On 12 October 2011 17:09, Forest Wilkinson <[email protected]> wrote: >>>> >>>> >> >> > When I use WSGIScriptAliasMatch, even with the arguments you >>>> >> >> > suggested, I get a ton of these errors in apache's error.log: >>>> >>>> >> >> > Request exceeded the limit of 10 subrequest nesting levels due to >>>> >> >> > probable confguration error. Use 'LimitInternalRecursion' to >>>> >> >> > increase >>>> >> >> > the limit if necessary. Use 'LogLevel debug' to get a backtrace. >>>> >>>> >> >> > Followed by this error: >>>> >>>> >> >> > child pid 12345 exit signal Segmentation fault (11) >>>> >>>> >> >> > When I use this: >>>> >>>> >> >> > AliasMatch ^/(?!auth|sitepage) /var/moin/apidoc/server/moin.wsgi/$1 >>>> >>>> >> >> > I get those same errors, as if I had used WSGIScriptAliasMatch. >>>> >>>> >> >> > When I use this: >>>> >>>> >> >> > AliasMatch ^/(?!auth|sitepage) /var/moin/apidoc/server/moin.wsgi >>>> >>>> >> >> > The errors go away, but SCRIPT_NAME and PATH_INFO are wrong, as in >>>> >> >> > my >>>> >> >> > original post. >>>> >>>> >> >> > On Tue, Oct 11, 2011 at 23:00, Graham Dumpleton >>>> >> >> > <[email protected]> wrote: >>>> >> >> >> On 12 October 2011 16:47, Forest Wilkinson <[email protected]> >>>> >> >> >> wrote: >>>> >> >> >>> AliasMatch ^/(?!auth|sitepage).* >>>> >> >> >>> /var/moin/apidoc/server/moin.wsgi >>>> >>>> >> >> >>> WSGIScriptAliasMatch ^/(?!auth|sitepage).* >>>> >> >> >>> /var/moin/apidoc/server/moin.wsgi >>>> >>>> >> >> >> What happens if you use: >>>> >>>> >> >> >> WSGIScriptAliasMatch ^/(?!auth|sitepage) >>>> >> >> >> /var/moin/apidoc/server/moin.wsgi/$1 >>>> >>>> >> >> >> Don't have .* on left hand side. It will match leading path. >>>> >>>> >> >> >> Can't remember if /$1 will be required to get SCRIPT_NAME to be >>>> >> >> >> empty. >>>> >>>> >> >> >> Graham >>>> >>>> >> >> >>> On Tue, Oct 11, 2011 at 22:39, Graham Dumpleton >>>> >> >> >>> <[email protected]> wrote: >>>> >> >> >>>> Provide both the WSGIScriptAliasMatch and AliasMatch directive >>>> >> >> >>>> lines you used. >>>> >>>> >> >> >>>> Graham >>>> >>>> >> >> >>>> On 12 October 2011 16:29, Forest <[email protected]> wrote: >>>> >> >> >>>>> Hi, all. >>>> >>>> >> >> >>>>> I believe I should be able to use apache's AliasMatch directive >>>> >> >> >>>>> instead of WSGIScriptAlias, so long as I also use SetHandler >>>> >> >> >>>>> wsgi- >>>> >> >> >>>>> script and Options +ExecCGI in my <Directory> section. This >>>> >> >> >>>>> is mostly >>>> >> >> >>>>> working for me, except that SCRIPT_NAME is being set to the >>>> >> >> >>>>> entire >>>> >> >> >>>>> path of each request's URL, and PATH_INFO is always empty. >>>> >> >> >>>>> Unfortunately, this causes MoinMoin to misbehave. >>>> >>>> >> >> >>>>> When I use WSGIScriptAlias, SCRIPT_NAME and PATH_INFO are set >>>> >> >> >>>>> correctly. >>>> >>>> >> >> >>>>> What must I do to get modwsgi to set SCRIPT_NAME and PATH_INFO >>>> >> >> >>>>> correctly when using AliasMatch? >>>> >>>> >> >> >>>>> (Incidentally, I'm using AliasMatch in order to route all >>>> >> >> >>>>> paths except >>>> >> >> >>>>> a couple of specific ones to MoinMoin's wsgi application. I >>>> >> >> >>>>> tried >>>> >> >> >>>>> WSGIScriptAliasMatch with the same regular expression, but >>>> >> >> >>>>> this caused >>>> >> >> >>>>> apache to fail with recursion errors and segmentation faults >>>> >> >> >>>>> in the >>>> >> >> >>>>> error log.) >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "modwsgi" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/modwsgi?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/modwsgi?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
