On Jan 27, 3:34 pm, James Slagle <[email protected]> wrote:
> A while back we migrated our app over to mod_wsgi from mod_python. We
> had been using PythonAuthenHandler with mod_python previously for a
> custom authentication handler. I posted to the group at the time, and
> got some helpful feedback about using WSGIAuthUserScript or
> WSGIAccessScript to accomplish what we needed to do.
>
> In the end, I had to make use of WSGIAuthUserScript because the client
> SSL certificate was not available via mod_ssl.var_lookup when using
> WSGIAccessScript. It seems mod_ssl does not make that data available
> until after the WSGIAccessScript has run. We need access to the
> client certificate to do our custom authentication, so I had to use
> WSGIAuthUserScript instead.
>
> The main issue for us with using WSGIAuthUserScript was that our
> requests weren't actually using HTTP basic auth, so then the
> WSGIAuthUserScript did not get run. I worked around this by setting
> the Authorization header on every request using mod_headers and the
> RequestHeader config. This seemed to work, I got the script to run
> this way and was able to do the authentication.
>
> That has turned into a separate issue though, because some other
> requests to the web server actually do use basic auth. In this case,
> the Authorization header ends up getting munged by apache, the 2
> values (one actually provided, and one set via RequestHeader) are
> concatenated on a single header line separated by a comma. Most web
> apps/frameworks don't handle this at all. We end up breaking any
> other web app depending on basic auth that is installed along side our
> mod_wsgi app under apache (such as a Rails app for instance). The
> RequestHeader config has to be at the server level for apache config,
> because I had to use the "early" keyword to get the header to be
> applied early enough in the request lifecycle so that the
> WSGIAuthUserScript would get run.
>
> My question is, is there a cleaner or easier way to do what I'm trying
> to do using just mod_wsgi? I just need to set a python script to run
> for a <Directory> stanza in my apache config to either allow or deny
> access (with the client certificate available if one was supplied) on
> every request that is handled by that <Directory>. Is this
> functionality something that could easily be added to mod_wsgi,
> perhaps through a different apache access hook? I wouldn't mind
> helping with that effort if I could get a few pointers. Thanks.
I have a small patch for mod_wsgi that has enabled me to use
WSGIAccessScript and have access to the client SSL certificate.
The patch makes it so that the mod_ssl hooks that are registered at
APR_HOOK_MIDDLE are run before wsgi_hook_access_checker
hook. This makes it so that I can use mod_ssl.var_lookup to get the
value of the client certificate.
Here's the patch against mod_wsgi tip:
diff -r 8633d5afeea8 mod_wsgi.c
--- a/mod_wsgi.c Tue Apr 19 11:33:51 2011 +1000
+++ b/mod_wsgi.c Fri Jan 27 20:52:25 2012 -0500
@@ -14880,6 +14880,7 @@
#endif
static const char * const p6[] = { "mod_python.c", NULL };
+ static const char * const p7[] = { "mod_ssl.c", NULL };
ap_hook_post_config(wsgi_hook_init, p6, NULL, APR_HOOK_MIDDLE);
ap_hook_child_init(wsgi_hook_child_init, p6, NULL,
APR_HOOK_MIDDLE);
@@ -14908,7 +14909,7 @@
ap_register_provider(p, AUTHZ_PROVIDER_GROUP, "wsgi-group",
AUTHZ_PROVIDER_VERSION,
&wsgi_authz_provider);
#endif
- ap_hook_access_checker(wsgi_hook_access_checker, NULL, n5,
APR_HOOK_MIDDLE);
+ ap_hook_access_checker(wsgi_hook_access_checker, p7, n5,
APR_HOOK_MIDDLE);
#endif
}
We're actually using mod_wsgi 3.3, and the patch works there as well.
--
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.
