Файл cookie сеанса Django потерян из-за нескольких одновременных запросов

Question

Я создаю приложение, в котором клиент время от времени пингует сервер (давайте не будем вдаваться в причину).Когда сервер обрабатывает эти запросы, он проверяет, вошел ли клиент в систему или нет, используя request.user.is_authenticated ()

. Это выглядит примерно так:что иногда сервер получает запрос на вход в систему, за которым сразу же следует запрос ping (от того же пользователя).Затем клиент успешно вошел в систему, ответ возвращается с новым идентификатором сеанса (вошедшего в систему пользователя) и (я полагаю, что) старый идентификатор сеанса (для анонимного пользователя) удаляется.Когда запрос проверки связи обрабатывается, его запрос содержит старый идентификатор сеанса.Таким образом, запрос ping возвращается с третьим идентификатором сеанса, и при следующем запросе, который делает клиент, клиент больше не входит в систему.

Мой код для входа выглядит примерно так:* Есть ли у вас какие-либо предложения о том, как избежать этой проблемы?Желательно без привлечения клиента.

Спасибо.

Answer 1

Вероятно, это слишком грязно для обработки этого на сервере, потому что вам придется создать некую семафорную систему, которая также будет пытаться угадать, есть ли в данный момент какой-либо пинг от клиента, который также проходит проверку подлинности. Мое предложение было бы просто изменить код клиента, чтобы он не пинговал, пока он ожидает ответа на свой запрос на вход в систему.

Answer 2

Вы можете создать альтернативу стандартному методу contrib.auth.login , который сохраняет тот же идентификатор сеанса, а не генерировать новый, либо используя пользовательский сервер аутентификации, который не генерируетновый ключ или путем создания пользовательского бэкэнда сеанса, который переопределяет метод cycle_key () в contrib.sessions.base для повторного использования того же ключа.

НО: подумайте, что вы можете открытьдо повторного использования одного и того же ключа сеанса - в зависимости от того, где используется эта система, вы станете более открытыми для перехвата сеанса (т. е. для отслеживания можно использовать только один идентификатор сеанса), а также из-за возможных проблем, когда кэши могутвернуть содержимое страницы unauth вместо содержимого страницы авторизации, потому что идентификатор сессии технически одинаков и кеш не может определить разницу между двумя ситуациями: и т. д., и т. д. и т. п.

Короче говоря: есть причинапо умолчанию он работает так, как работает.