Отмена зимнего времени — проблемы с авторизацией пользователей через cookies. Как решить средствами сервера?
Доброго времени суток!
Помимо уже описанных эффектов, связанных с переездом в GMT+3 (Беларусь), мы столкнулись еще с одним.
Дано: Система администрирования веб-сервиса с авторизацией через логин-пароль, использующая Cookie. время неактивной сессии администратора установлено в 10 минут.
Симптом проблемы: Администратор (в общем случае авторизуемый Пользователь) входит, вводит корректные логин и пароль, система принимает его (выводится сообщение об успешной авторизации) и пользователь опять переходит на страницу с просьбой ввести логин и пароль. Оставим в стороне очевидную ошибку разработчиков, которые поленились вывести системное сообщение о том, почему так происходит.
Причина: Оказалось, что пользователь (из Беларуси) на своей локальной машине установил правильное локальное время, но не сменил свой часовой пояс, оставшись в GMT+2.
Механизм действия причины: При правльном логине и пароле система устанавливает Cookie с временем жизни в +10 минут. Реальное время клиента, приходящее на сервер в таком случае составляет -1 час к реальному времени сервера, соответственно, устанавливаемая кука с длительностью в 10 минут является уже заранее просроченной и соответственно, необходима повторная авторизация пользователя.
Решение: Установить временную зону на компьютере пользователя правильно, для Беларуси в GMT+3, и корректно настроить локальное время на компьютере пользователя.
Внимание, вопрос: как эту проблему решить средствами сервера и вообще не зависеть от таких нюансов на стороне клиента?
Куки устанавливаются не просто +10 мин, а указывается конкретное время (по UTC/GMT)
Если речь идет о 10 мин, то возможно у клиента и/или у сервера часы неточные.
Спасибо, но возможно я не корректно выразился. Указывается _конкретное_ время. Оно _всегда_ устанавливается по UTC/GMT в куки. Проблема как раз в том, что в когда браузер смотрит валидность куки (а это он делает в момент запроса страницы, следующей за страницей авторизации) он переводит время жизни в локальное время пользователя исходя из локальных настроек часового пояса. И при такой ситуации, как я описал, _браузер_ при следующем запросе удаляет куку как уже истекшую, а сервер уже ее видит и предлагает авторизоваться снова. И происходит вечный цикл. В том и дело, что часы (а вернее часовой пояс) пользователя в данном случае неточны. Вопрос был, как не сильно меняя текущую схему авторизации устранить эту проблему, копая _только_ на стороне сервера.
Устанавливать куку с сроком жизни не 10 минут, а сутки, или вообще без срока протухания. На сервере, естественно, хранить сессию только 10 минут. Таким образом клиент не будет самовольно стирать куку. А сервер, если получает просроченную куку — то стирает её и редиректит на страницу авторизации.
То есть единственно, что нужно изменить — при установке куки не указывать дату истечения.
Проверка свежести куки на стороне сервера у вас уже должна быть реализована (мы же не доверяем клиенту?).
Вы абсолютно правы. Ставим атрибут expire = 0 и куки будут жить на клиенте до конца его сессии, либо пока куки не протухнут на сервере. Таким образом авторизоваться не составит труда при каком угодно времени как на сервере, так и на клиенте.
