Copterfly / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

Add WSGISetAuthEnvironment and WSGIUnsetAuthEnvironment directives. #73

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The existing Apache SetEnv directive is harnessed as a means to set WSGI 
environment variables 
passed to applications. Because this directive is only processed just before 
the content handler 
phase, it is no good for setting variables seen by the 
access/authentication/authorisation hooks 
in their WSGIish like environment.

This is a bit of a pain as it means that any configuration required by those 
hooks has to be 
defined within the hook functions modules rather than in Apache configuration.

To allow the hooks to be passed configuration from Apache configuration file, 
look at adding 
WSGISetAuthEnvironment directive.

Note that this would only apply to the aaa functions and not the content 
handler itself. This is 
the case as the use of the same directive for both would allow a user in a 
.htaccess file to 
override aaa functions configuration when they shouldn't be able to. Thus 
SetEnv still use for 
content handler with it being able to be used in .htaccess file if FileInfo 
override set. The 
WSGISetAuthEnvironment directive would only be allowed to be used in .htaccess 
file if AuthInfo 
override set.

One might also add WSGISetEnvironment and WSGIUnsetEnvironment for the content 
handler as 
an alternate to SetEnv and UnsetEnv. The only purpose in doing this though 
would be if one 
wanted to allow variables for WSGI applications to be set which weren't also 
going to be passed 
to CGI applications or other Apache modules.

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 28 Mar 2008 at 11:14

GoogleCodeExporter commented 9 years ago
Secondly, when using the daemon mode of mod_wsgi 2.0+ custom environment 
variables
are not preserved. For example, setting a process environment variable with 
SetEnv to
select the application's profile or environment (i.e. development, production,
testing) is impossible without using a wrapper script when running in daemon 
mode.

Perhaps even a parameter to WSGIDaemonProcess like:
WSGIDaemonProcess myprocess ... setenv=ENV=development
.. or similar.

Is there a way of doing this per application/script? I haven't really looked 
into it
in enough detail.

Original comment by samuel.c...@gmail.com on 3 Nov 2008 at 7:28

GoogleCodeExporter commented 9 years ago
SetEnv isn't doing what you expect because this isn't CGI.

The original purpose of SetEnv for CGI was to set process environment 
variables. With mod_wsgi, they only serve 
to set variables in the WSGI environ dictionary which is passed to the WSGI 
application as an argument.

The moral of the story is that you should not be relying on process environment 
variables in WSGI applications, it 
is bad practice and can actually cause lots of problems in a multithreaded 
application. Unfortunately, some Python 
web frameworks carry over this practice.

Suggest you take this discussion over to mod_wsgi list on Google groups and we 
can discuss there what it is you 
are actually trying to achieve.

Original comment by Graham.Dumpleton@gmail.com on 3 Nov 2008 at 9:50

GoogleCodeExporter commented 9 years ago
Decided that don't want to have mod_wsgi specific directives for setting a 
second set of variables to be later 
integrated into WSGI environment as it just gets too messy.

Certainly, what variables are passed shouldn't be derived from a specific URL 
context from SetEnv directives 
or similar. If it is desired that configuration variables be able to be passed 
from Apache configuration for a 
specific authnz hook, then they perhaps should be an option that can be 
supplied to the directive which sets 
up the hook to do it and not a separate directive.

Original comment by Graham.Dumpleton@gmail.com on 12 Mar 2009 at 5:11