> On 1 Aug 2017, at 1:30 am, Cheyenne Wills <cheyenne.wi...@gmail.com> wrote: > > I have a situation where I need to return a 403 response back the client > either during the check_password phase or during the authorization phase.
Apache doesn't allow that. Authentication providers can only say whether access is granted or not. It always translates a failure of an authentication provider into a 401. > Currently I have been using a set of mod_python handlers to perform this, > but have run into a situation where I am now needing to wrap a CGI script and > mod_python seems to conflict with the built in CGI handler (I can either get > the cgi script to work, or the mod_python handler to perform the > authentication/authorization). > > I was able to rework my mod_python handlers to work as mod_wsgi authn/authz > handlers, but all I can get is a 401 (bad credentials) or 200 (success) > response. There are times I need to be able to respond with a 403 > (forbidden). I need to be able to tell the client "yes -- you got the right > credentials, but you are currently forbidden from accessing that particular > url). > > The actual content providers cannot be altered (e.g. they are established 3rd > party facilities and not "my code that can be altered"). In addition the > client side is not a browser, but commandline clients that happen to be using > http protocol. > > Unfortunately the allow_access routine (which can return a 403) is called > before I have access to the userid. Apache performs access controls, based on host/ip etc, before it does authentication. > I did stumble across the following -> > https://groups.google.com/forum/#!topic/modwsgi/pGPU6JSNh1E which touches the > the same issue. > > I have started to poke around in mod_wsgi.c and have thought of adding an > option that would allow either check_password or groups_for_user to set a > return status, but would like to know if there is a "better" way to handle > this. It can't be done by changing mod_wsgi as it is the Apache APIs which control how it works. The closest you will get is to use a authorisation handler (different to authentication). This is implemented by groups_for_user(). http://modwsgi.readthedocs.io/en/develop/user-guides/access-control-mechanisms.html#apache-group-authorisation <http://modwsgi.readthedocs.io/en/develop/user-guides/access-control-mechanisms.html#apache-group-authorisation> The groups_for_user() function is given the user and WSGI environ dictionary, so you can also check the URI. Just be warned that you only have access to the raw REQUEST_URI and you have to be very careful about using that as it hasn't been normalised. If you don't normalise it yourself before checking the value then it can be possible to play around with the URI and defeat your check by giving a URI which would normalise to the same value, but wouldn't be seen as the same on straight comparison. Code might therefore me. import posixpath def groups_for_user(environ, user): print('GROUP', user, environ['REQUEST_URI']) path = posixpath.normpath(environ['REQUEST_URI']) # Some criteria to check. if path == '/forbidden': return [''] return ['let-me-in'] In Apache configuration then have: WSGIAuthGroupScript .../some/path/auth.wsgi' Require wsgi-group let-me-in AuthzSendForbiddenOnFailure On The AuthzSendForbiddenOnFailure directive must be set to On, else Apache will still return 401. Do head the warnings in Apache documentation: http://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authzsendforbiddenonfailure <http://httpd.apache.org/docs/2.4/mod/mod_authz_core.html#authzsendforbiddenonfailure> Where it says: """Modifying the response in case of missing authorization weakens the security of the password, because it reveals to a possible attacker, that his guessed password was right.""" So that is the closest you will get. You can't dynamically have it return 403 rather than 401 for individual requests when failing authorisation. You can only set that AuthzSendForbiddenOnFailure for all authorisation failures. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to modwsgi+unsubscr...@googlegroups.com. To post to this group, send email to modwsgi@googlegroups.com. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
