Approximately Me

All WSGI applications I've touched so far have had test installations with extra access control. The applications have their own authentication systems restricting access to specific parts of the applications, and the overall access control to the test installations have been configured in Apache. Restricting access to a whole site in Apache is both simple and effective.

All installations have had the same problem: Apache puts the authenticated username in its REMOTE_USER variable, which is transferred to the WSGI application via Flup, and which makes the application believe that a user has been authenticated by the application. Web requests then typically fail because the application hasn't had the chance to set up the authenticated environment, or a user with the Apache username doesn't exist in the application. Luckily the fix is simple.

The WSGI applications I've worked on are loaded using Paste, passed to Flup, and managed by Apache 2 through mod_fcgid. The fcgi script with the fix is as follows:

#!/path/to/virtual/env/bin/python
config = '/path/to/config.ini'

if __name__ == '__main__':
    import logging.config
    logging.config.fileConfig(config)

    from paste.deploy import loadapp
    from flup.server.fcgi import WSGIServer
    WSGIServer(loadapp('config:' + config),
               environ={'REMOTE_USER': ''}).run()

As hightlighed in the code, an empty REMOTE_USER is passed to the Flup WSGI server, overriding the REMOTE_USER coming from Apache. The authentication solution in the application can then operate unaffected by the Apache authentication as long as it interprets an empty string as no value. Flup won't override the environment variable if you pass in None.

So now I don't have to re-figure this problem out whenever I add Apache access control to a WSGI application. It's here :)