Глава 17 Типовые решения для хранения состояния сеанса Сохранение состояния сеанса на стороне клиента (Client Session State)

Сохраняет состояние сеанса на стороне клиента

Принцип действия

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

В большинстве случаев для перемещения данных между клиентом и сервером исполь­зуется объект переноса данных (Data Transfer Object). Он может сериализовать свое содержимое для передачи по сети, тем самым позволяя перемещать весьма сложные структуры данных.

Клиент также нуждается в способе хранения данных. Если речь идет о толстом клиен­те, хранение данных может осуществляться за счет собственных структур приложения, например полей его интерфейса (хотя я бы предпочел застрелиться, чем поступать таким образом). Гораздо более удачным решением является хранение состояний сеансов в со­вокупности невизуализированных объектов, например в модели домена или в самом объ­екте переноса данных. В любом случае, это не такая уж серьезная проблема.

С HTML-интерфейсами дело обстоит немного сложнее. Существует три основных способа сохранения состояния сеанса на стороне клиента: параметры адреса URL, скрытые поля и файлы cookie.

Использование параметров адреса URL хорошо подходит для работы с небольшим количеством данных. Вообще говоря, для отображения Web-страницы с результатами выполнения запроса все адреса URL принимают то или иное количество параметров сеанса. Разумеется, объем сохраняемой информации существенно ограничен размерами адресов. Тем не менее данный метод прекрасно справляется с двумя-тремя параметрами, поэтому он весьма популярен для хранения на стороне клиента небольших значений на­подобие идентификаторов сеансов. Некоторые платформы автоматически перезаписы­вают адреса URL, добавляя к ним идентификаторы сеансов. Изменение адреса Web-страницы может повлиять на работу закладок, поэтому данную схему хранения не рекомендуется использовать на коммерческих сайтах, связанных с обслуживанием по­требителей.

Скрытое поле — это поле, значение которого передается обозревателю, но не отобра­жается на Web-странице. Наличие скрытого поля задается дескриптором вида <input type = "hidden">. Чтобы сохранить данные на стороне клиента, сервер сериализует состояние сеанса, помещает его в скрытое поле при отправке ответа и вновь считывает при получении следующего запроса. Как только что отмечалось, помещаемые в скрытое поле данные должны быть сериализованы. Обычно в качестве формата сериализации применяют XML, хотя, как известно, он слишком "многословен". Вместо этого данные можно сериализовать и в какой-нибудь другой текстовый формат. Не забывайте, однако, что значение скрытого поля скрыто только во время отображения; чтобы добраться к этому значению, достаточно просмотреть исходный код страницы.

Остерегайтесь сайтов, содержащих старые Web-страницы или страницы с фиксиро­ванными адресами. Переместившись на них, вы потеряете всю информацию о состоянии сеанса.

Последний, пожалуй наиболее спорный, метод хранения состояний сеанса — это ис­пользование файлов cookie, которые автоматически передаются от сервера к клиенту и наоборот. Как и при работе со скрытыми полями, помещаемые в файл cookie данные нужно сериализовать. Объем сохраняемой информации ограничивается размерами фай­лов — они не должны быть слишком большими. Кроме того, многим пользователям не нравится присутствие файлов cookie, поэтому их отключают, в результате чего сайт пере­станет функционировать. Тем не менее в наше время все больше и больше сайтов осно­ваны на использовании файлов cookie, поэтому подобные неприятности случаются не­часто. И конечно, наличие этих файлов не представляет никакой опасности для чисто "домашних" систем.

Не забывайте: файлы cookie безопасны не более чем другие способы хранения ин­формации, а значит, несанкционированное использование данных возможно и здесь. Кроме того, файлы cookie работают только в пределах одного имени домена, поэтому, если ваш сайт разнесен по нескольким доменам, файлы cookie не смогут перемещаться между его частями.

Некоторые платформы автоматически определяют, разрешено ли на стороне клиента использование файлов cookie; если это не так, они применяют перезаписывание адресов URL. Данная схема позволяет легко сохранять на стороне клиента небольшие объемы сведений о сеансе.

Назначение

Типовое решение сохранение состояния сеанса на стороне клиента обладает массой преимуществ. В частности, оно поддерживает использование серверных объектов без со­стояний, обеспечивая максимальную степень кластеризации и устойчивости к отказам.

Разумеется, при отказе системы клиента все данные будут утеряны, однако в подобных ситуациях большинство клиентов ожидают именно такого исхода.

Количество аргументов против сохранения состояния сеанса на стороне клиента стре­мительно возрастает с увеличением объема сохраняемой информации. Все перечислен­ные схемы прекрасно подходят для хранения нескольких полей, однако при наличии больших объемов данных вопросы их размещения и временные расходы, вызванные пе­редачей вместе с каждым запросом большого количества информации, становятся весьма критичны. Это особенно верно для HTTP-клиентов.

Применение данного типового решения связано и с проблемами безопасности. Све­дения, отсылаемые клиенту, могут быть перехвачены и изменены. Единственный способ предотвратить подобные поползновения — воспользоваться шифрованием, однако шифрование и дешифровка каждого запроса может нанести большой урон производи­тельности приложения. С другой стороны, все, что не было зашифровано, является по­тенциальной мишенью для любознательных глаз. Как правило, их хозяева обладают к тому же "пронырливыми" пальцами, поэтому не ожидайте, что сведения о состоянии се­анса вернутся в том же виде, в каком они были отосланы. Все данные, возвращаемые клиентом, должны быть подвергнуты тщательной проверке на правильность.

Без сохранения состояния сеанса на стороне клиента не обойтись при необходимости хранить идентификаторы сеансов. К счастью, идентификатор — это всего лишь число, поэтому проблем с его обработкой в перечисленных выше схемах быть не должно. Тем не менее попытки перехвата данных случаются и здесь, например если злоумышленник из­менит идентификатор своего сеанса, чтобы перехватить сеанс другого пользователя. Для снижения подобного риска большинство платформ генерируют идентификаторы се­ансов методом случайных чисел; если же такая возможность отсутствует, попробуйте воспользоваться хэшированием.