Недавно у меня возникла проблема на моем сайте на Django, из-за которой вход в систему не будет выполнен без ошибок, о которых пользователю сообщалось после нескольких дней работы сайта. Уже вошедшие в систему сессии продолжают работать нормально, но новых входов в систему не может быть.
Соответствующая информация:
Я использую обычную django.contrib.auth аутентификацию
Я использую PostgreSQL для БД через django.db.backends.postgresql_psycopg2 бэкэнд
Я работаю на OSX 10.6.7 с Python 2.6.1 и Django 1.3
Django работает в режиме FastCGI за nginx
У меня такое ощущение, что в какой-то момент в соединении / сокете с БД что-то ломается, потому что, если я убью Django и перезапущу его, все снова будет работать нормально (т.е. сама БД определенно не перегружена и может быть доступным просто с помощью инструмента командной строки psql.
К сожалению, в журналах ничего не говорится об ошибке (ну, по крайней мере, ничего не выводится через обычный модуль Python logging, который позволяет перехватывать все мои журналы), и в веб-браузер не сообщается об ошибках , Все, что видит клиент, это то, что его снова отправляют на страницу входа, как будто они только что обновили свой браузер.
Любая помощь высоко ценится.
Не уверен, что это актуально, но мои промежуточные классы:
MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.transaction.TransactionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
)
UPDATE
Просматривая журналы доступа nginx, я вижу, что логин на самом деле работает ненадолго, а потом вдруг не работает:
"POST /accounts/login/ HTTP/1.1" 302 5 "https://myapp.com/accounts/login/?next=/orders"
"GET /orders HTTP/1.1" 301 185 "-"
"GET /orders HTTP/1.1" 302 5 "-"
"GET /accounts/login/?next=/orders HTTP/1.1" 301 185 "-"
"GET /accounts/login/?next=/orders HTTP/1.1" 200 1297 "-"
Как видите, вход в систему работает, и клиент перенаправляется на «следующий» URL (/ orders), но затем третья строка перенаправляет (302) клиента обратно на страницу входа, предположительно потому, что @login_required Декоратор (который применяется к контроллеру / orders) определил, что они на самом деле не вошли в систему.
Для сравнения, это успешная последовательность входа в систему:
"POST /accounts/login/ HTTP/1.1" 302 5 "https://myapp.com/accounts/login/?next=/orders"
"GET /orders HTTP/1.1" 301 185 "-"
"GET /orders HTTP/1.1" 200 59364 "-"
И логин с неправильным паролем (POST возвращается с 200 вместо 302):
"POST /accounts/login/ HTTP/1.1" 200 1426 "https://myapp.com/accounts/login/?next=/orders"
Разница между обычным и неработающим логином заключается в том, что клиент получает 200 OK за / заказы вместо 302 обратно на страницу входа. Я понятия не имею, как промежуточное программное обеспечение авторизации может разрешить вход в систему, а затем сразу же выгнать пользователя обратно. Есть ли здесь возможное состояние состязания, когда контроллер входа в систему не смог сохранить состояние входа в БД во время, чтобы контроллер / orders увидел его и позволил пользователю оставаться в системе?
Также - я заметил, что перезапуск Django не обязательно необходим для исправления проблемы - иногда сервер просто чудесным образом начинает позволять клиентам снова войти в систему.