Loading...

modwsgi@googlegroups.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

[modwsgi] Re: mod_wsgi and access scripts for authentication James Slagle Fri Feb 03 01:09:42 2012


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.