masterspammer (masterspammer) wrote,
masterspammer
masterspammer

Про сессии

Задача - реализовать сессии так, чтобы аутентификация и авторизация работали надёжно и не упирались в одно узкое место. Подразумеваемое узкое место - хранилище данных сессий и данных пользователей, единое для всех узлов кластера за балансировщиком нагрузки. Одно решение очевидно - привязка сессии к конкретному узлу на балансировщике, но сейчас я о другом решении.

Это решение таково - в cookie кладётся не id сессии, а сами её данные, подписанные сервером. Данные могут быть прочитаны клиентом (и использованы, например, при отображении интерфейса), но не могут быть им изменены - для подписи требуется ключ, известный серверу (и единый для всех нод кластера если есть балансировка нагрузки), но неизвестный клиенту. Все изменения производятся сервером, как обычно и бывает.

Пусть cookie sess=[данные][подпись] - где данные-сереализованное содержимое сессии (с отображением на множество допустимых символов, может немного сжатое) неизвестного размера, а подпись - хэш-сумма известной длины. Клиент может отрезать подпись и десериализовать данные.

Сервер получает правильное значение подписи следующим образом:
подпись=hash(данные+секретный_ключ+iphash(client_ip, prixy_ip)+uahash(useragent))
Эта функция используется и для проверки полученных от клиента данных и для создания/изменения сессии.
Здесь hash - какая-нибудь криптостойкая функция;
iphash - функция f(x,y)=x+y для жёсткой привязки к IP или функция, заменяющая младший байт адреса на 0 (чтоб при переприсоединении мобильного клиента, получающего новый IP но в той же сети, не терять сессию);
uahash - функция f(x)=x для жёсткой привязки к браузеру с учётом полной версии или какая-то функция обработки версий, чтоб сессия сохранялась при обновлении браузера;
'+' - склейка строк.

Возможен оригинальный вариант устаревания сессий - пусть у нас есть изменяемый (например, раз в сутки) секретный ключ, при проверке используются сначала его актуальное, а в случае неудачи - предыдущее значение. При изменении всегда используется актуальное значение, при прохождении проверки с предыдущим значением сессия переподписывается принудительно. Тогда сессия живёт от суток (гарантированно) до двух (и никогда больше), автоматически продлеваясь при любом использовании.

Использование большего числа предыдущих значении и меньшего интервала обновления позволяют задавать время устаревания более точно - при обновлении раз в час и использовании 23-х предыдущих значений, погрешность не превысит одного часа.
Tags: cms, javascript, Интерфейс, Философское
Subscribe

  • (no subject)

    Так получилось, что у прошлых (до PC) моих компьютеров прерываний или не было вообше или был таймер с фиксированной частотой. У Z80 (если подходить…

  • Техноорки

    Началось с того, что у жены в машине начал часто загораться индикатор аккумулятора и иногда возникать глюки зажигания на полной нагрузке…

  • Заусенец

    Переклеил, ага, но что-то чуйка не даёт считать дело законченным. Магнит купил, определил и подписал полюса, плюсы и минуса. Парный динамик уже…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments