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.
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. 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. Thanks in advance. Cheyenne Wills -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
