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.
