Hi Graham, thanks for you response.
I'm already aware of the possibilty of hijacking the WSGIAccessScript.
It is precisely because this script is so similar to what I want that
I thought we might be able to add a second hook for the "arbitrary
validation" case. For all I care, using this boils to two simple
issues:
1. From my current understanding, I cannot redirect to a custom
login page from WSGIAccessScript because `allow_access()` returns a
boolean (although in the script I currently want to port from
mod_python to mod_wsgi, I don't need this feature, I'm planning a
simple extension to my code base where this could prove very useful).
2. The documentation for WSGIAccessScript is heavily biased
towards "host access control", making use of WSGIAccessScript *seem*
like a hack.
I understand adding simple-looking features can want rapidly increases
mod_wsgi's complexity, but we're already not far from having a clean
solution. I mean, even the function name `allow_access()` seems
resonable as a general-purpose access validation function.
Can you implement support for an alternate return value (i.e. a string
containing a URL) to support redirection and update the docs to state
that WSGIAccessScript is the official mod_wsgi way of replacing
mod_python's PythonAuthzHandler?
Thanks,
André
On Fri, Oct 22, 2010 at 1:14 AM, Graham Dumpleton
<[email protected]> wrote:
> Not sure it helps, but WSGIAccessScript might be able to be hijacked
> to do what OP required. One would ignore the hostname bit and just
> interrogate the environ to validate stuff and return True or False.
> Returning false will cause HTTP_FORBIDDEN to be returned. If True,
> flows through to subsequent handlers. You can't do a custom error page
> from it, but you could use ErrorDocument for forbidden error status to
> generate one.
>
> As to further changes to mod_wsgi itself to support further hooking in
> Apache, that will almost certainly never happen. It has already got
> too messy as it is.
>
> Graham
>
> On 19 October 2010 18:46, Deron Meranda <[email protected]> wrote:
>> Yes, I too have had similar issues with converting complex
>> mod_python-based auth* code into something equivalent in mod_wsgi. In
>> my case I was using the mod_python PythonAccessHandler directive
>> (along with PythonOption directives).
>>
>> Graham and I had a somewhat lengthy exchange on this mailing list back
>> in mid-March 2010; with lots of interesting discussion; and a teaser
>> from Graham:
>>
>> "...I am still contemplating various things and not much time to write
>> actual code, so I'll have more to say about all this another time when
>> have worked out what to do."
>>
>> Not that I expect him to remember or that he should've been doing
>> anything; he's certainly been busy enough supporting the main
>> functionality that 99% of everybody else needs and championing the
>> whole WSGI community. Nonetheless it's still left me curious.
>>
>> I have more time now so I really should dive back into this issue more
>> seriously and see if I can come up with something constructive.
>>
>> --
>> Deron Meranda
>> http://deron.meranda.us/
>>
>> --
>> 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.
