У нас есть несколько проблем с тем, что пользователи выходят из системы и / или не могут войти в наше приложение Django. У нас есть одна база данных, несколько серверов переднего плана и балансировщик нагрузки nginx с использованием ip_hash, и мы испытываем две проблемы, я не уверен, связаны ли они.
Во-первых, многие пользователи выходят из системы, если их обращения перемещаются с одного внешнего сервера на другой, например, если один из них отключен для обслуживания. Просто используйте стандартное хранилище сеансов базы данных Django и пакет аутентификации, поэтому похоже, что это не должно быть проблемой.
Во-вторых, у некоторых пользователей возникают проблемы со входом в систему. После того, как они прошли аутентификацию (и подтвердили, что их sessionid совпадает с идентификатором их пользователя в базе данных), сайт отвечает на их запросы, как если бы они не вошли в систему. Они могут попытаться войти снова и получить новый идентификатор сеанса, но все равно будут получать страницы, как если бы они были анонимными. Я не могу повторить это, поэтому более глубокое тестирование затруднено. Я не уверен, что django каким-то образом не может распознать сеанс, или, возможно, страницы кешируются для них (подтверждено, что это не кеш браузера). Главная страница сайта обслуживается заголовками управления кешем: no-cache, max-age = 0, must-revalidate, и django должен выполнять перенаправление, если пользователь аутентифицирован, чего не происходит.
Мы приветствуем любые предложения о том, почему это может происходить или что искать.
Похоже, это должно сработать. Просто чтобы подтвердить: есть ли у вас django.contrib.sessions в установленных приложениях? Это установит сеансы с поддержкой базы данных, так что не имеет значения, какой интерфейс вы используете.
Другая возможность заключается в том, что вы неправильно устанавливаете файлы cookie. Если кто-то оказывается на разных интерфейсных машинах, отражают ли это домены? Например, перенаправляются ли они на fe1.yourapp.com или fe2.yourapp.com, или они всегда попадают на www.yourapp.com?
Один случай, когда я видел нечто подобное, - это когда люди могли попасть либо на yourapp.com, либо на www.yourapp.com, а файлы cookie были установлены по-другому - если вы сначала перешли на субдомен, ваш файл cookie не будет передан, если вы позже попал в базовый домен. Нашим несколько неэлегантным решением было перенаправить всех на поддомен www.