Phew! I just finished wrestling with a TransactionMiddleware ordering issue.
Basically, if TransactionMiddleware is after SessionMiddleware (as suggested by the docs*) then a login operation, as done by the default login view, is only committed to the session when Django is running in debug mode. With DEBUG = True, everything works. With DEBUG = False, the login view will accept the credentials and reply with a redirect to the next page, but on the next page the user is not logged in. What's funny is that runserver --insecure somehow manages to make it work even in production mode, while runserver --nostatic doesn't break it for debug mode. And this on a view that has hardly anything to do with static files! Here is a summary: DEBUG = True runserver OK runserver --nostatic OK DEBUG = False runfcgi BROKEN runserver BROKEN runserver --insecure OK Only by looking at the queries issued by Django with a network inspector** did I notice the transaction issue. In production mode, Django fails to commit the transaction, after the login view puts the auth information into a newly created session, just before returning a 302 Found response to next page. I solved the issue (or maybe I just worked around it) by putting TransactionMiddleware before SessionMiddleware. But I think it warrants a closer look by one of the Django gurus, to update the documentation if nothing else. Tobia * https://docs.djangoproject.com/en/1.3/topics/db/transactions/ ** the quick and handy tcpick http://tcpick.sourceforge.net/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.