WSGI Regression 1.4 -> 1.5?

86 views
Skip to first unread message

Hanne Moa

unread,
Nov 1, 2013, 6:30:04 AM11/1/13
to django-d...@googlegroups.com
I have an auth-backend inheriting from model backend that works on 1.3.x and 1.4.x but does not work on 1.5.x. The only difference between the systems is the version of Django.

After much comparing and cursing and tearing of hair, it turns out what has changed is how Django behaves under mod_wsgi with WSGIDaemonProcess under Apache 2.2.22 prefork.

This works regardless:

WSGIDaemonProcess foo processes=1 threads=20 ...
WSGIDaemonProcess foo processes=1 threads=1 ...
WSGIDaemonProcess foo threads=1 ...
WSGIDaemonProcess foo ...

This no longer works with Django 1.5:

WSGIDaemonProcess foo processes=20 threads=20 ...
WSGIDaemonProcess foo processes=20 threads=1 ...
WSGIDaemonProcess foo processes=20 ...

The system is supposed to be running with
WSGIDaemonProcess foo processes=20 threads=20 ...

In sum: threading is ok, multiple processes is not. Furthermore, the default RemoteUserBackend works, the one inheriting from ModelBackend does not.

The problem seems to be that after successful authenticatiion and login, the session (cookies) isn't changed, since after a redirect, request.user is AnonymousUser.

According to http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading, how processes/threads are set up affects how shared data (globals, like module variables) are treated. I'm therefore wondering if somehing changed in how Django's wsgi deals with globals, or if there is change in globals usage in the auth backend system that will account for this.

Before I start making a publishable minimal version of the login backend that still fails, I'd like to know:

1. Are other people seeing this?
2. Is this affecting other parts of Django than just auth backends?
3. What other things should I be looking for?

Should there be a warning in the docs at least, that "processes" with WSGIDaemonProcess should be 1 or unset?


HM

Florian Apolloner

unread,
Nov 1, 2013, 9:22:47 AM11/1/13
to django-d...@googlegroups.com
First of all, using prefork and daemon mode is probably not the best choice you can make. I'd assume you are storing state in the process in your auth backend somehwere…

Hanne Moa

unread,
Nov 1, 2013, 10:25:48 AM11/1/13
to django-d...@googlegroups.com
On 1 November 2013 14:22, Florian Apolloner <f.apo...@gmail.com> wrote:

First of all, using prefork and daemon mode is probably not the best choice you can make. I'd assume you are storing state in the process in your auth backend somehwere…

Prefork thanks to php, which is used to authenticate and set (with the help of a 3rd party apache plugin) the user that RemoteUserBackend lookups up. WSGIDaemonProcess because that's what Graham Dumpleton recommends and because a dev-machine is running a zillion copies of several versions and WSGIDaemonProcess is easier to deal with then in my experience. It's quite the messy apache conf but It's only running the one wsgi script.
Reply all
Reply to author
Forward
0 new messages