Access to mod_ssl functions in mod_wsgi embedded mode.
Graham Dumpleton
information from access/authentication/authorization hooks, you can
now make use of the following in the environ dictionary.
mod_ssl.is_https: <built-in method ssl_is_https of mod_wsgi.Adapter
object at 0x101136a08>
mod_ssl.var_lookup: <built-in method ssl_var_lookup of
mod_wsgi.Adapter object at 0x101136a08>
The code change is in mod_wsgi subversion trunk.
Code is similar to what was previous explained in:
http://groups.google.com/group/modwsgi/browse_frm/thread/3993a7fff24911f6
Difference being that is now not a standalone extension module but
part of mod_wsgi itself. Being integrated, simpler to use.
is_https = environ['mod_ssl.is_https']
var_lookup = environ['mod_ssl.var_lookup']
# Are we running under SSL.
if is_https():
...
# Lookup SSL variables.
organisation = var_lookup("SSL_SERVER_I_DN_O")
The functions are also available to WSGI application itself when run
in embedded mode. They aren't available in daemon mode however.
If you need access to variables in daemon mode, then continue to use directive:
SSLOptions StdEnvVars
in Apache configuration.
Note that mod_ssl.is_https() will return whether or not client
connection truly was an SSL connection. In most cases this would be
the same as wsgi.url_scheme being 'https'.
Technically where using a nginx front end which is handling SSL, and
wsgi.url_scheme is being fiddled by passing headers from nginx to
indicate SSL was used and overriding HTTPS variable, then although
original client request may have been 'https', Apache could be using a
non SSL connection from front end nginx. Thus, variables only
available where Apache is the one accepting SSL connection from
client.
Regard this as experimental for now and please give feedback over
whether works or whether you think there are issues with this,
especially around allowing access to these variables in WSGI
application itself and whether that opens up risk of user getting
access to SSL certificate information that they shouldn't. It may be
safer to drop it from WSGI application and for that to expect
SSLOptions is used instead to populate variables direct into environ
dictionary. The latter at least means one consistent way of doing it
for WSGI application.
Graham
Graham Dumpleton
I have dropped these extensions from the WSGI application in embedded
mode now. Thus, to get SSL variables in WSGI application, still need
to use SSLOptions set to StdEnvVars.
After thinking about, doing this did indeed seem to make it more
consistent and also eliminated risk of stuff being passed through that
shouldn't be by default available.
Graham