Сеансы работы пользователей
Протокол НТТР изначально проектировался без поддержки механизма информации о состоянии сеансов работы пользователя. Индивидуальные запросы не связаны друг с другом, и НТТР-сервер не располагает средствами распознавания конечных пользователей между сеансами. Поэтому требуется определить способ идентификации пользователя, связать данные предыдущих и текущего сеансов работы пользователя.
ВНИМАНИЕ
Под сеансом понимается запрос пользователем одного документа с НТТР-сервера.
Существуют несколько способов организации сеансов, все они построены на наличии одной или нескольких переменных, которые ассоциируются с конкретным пользователем и устанавливают соответствие при каждом сеансе.
Данные сеанса могут храниться кик на стороне пользователя, так и на стороне сервера, в каждом методе хранения есть свои достоинства и недостатки.
ПРИМЕЧАНИЕ
При проектировании управляющего приложения для Интернет-каталога использовалась методика хранения информации на стороне клиента, при этом для сохранения конфиденциальности передаваемой информации и данных авторизации использовался защищенный протокол передачи данных 551.
В случае хранения данных на стороне пользователя всю необходимую информацию программа получает из строки запроса, предварительно подготовив сеансовые данные в предыдущем сеансе. Этот вариант плохо применим, если требуется использовать большое количество сеансовых переменных или необходимо обеспечить уровень безопасности без применения специальных мер. Положительной стороной этого метода является простота использования при минимальном числе используемых перемениых.
Хранение данных на стороне пользователя требует постоянных проверок на допустимость и соответствие данных, так как сеансовые переменные могут быть произвольно изменены пользователем.
ВНИМАНИЕ
Хранение сеансовых переменных на стороне сервера позволяет использовать все необходимые настройки с использованием сеансовых переменных, уникальных
для каждого пользователя. Однако для хранения пользовательской информации на стороне сервера необходима база данных. Это может быть и реляционная база данных, например МуSQL и обычный текстовый файл, в любом случае настройки пользователя или другая специфическая информация должны надежно сохраняться на сервере между сеансами пользователя.
ПРИМЕЧАНИЕ Возможности реляционной базы данных позволяют проводить намного более сложные манипуляции с данными, чем в текстовых базах данных.
Вместо хранения всей информации на стороне пользователя используется идентификатор сеанса, индивидуальный для каждого пользователя, с помощью которого данные из базы данных ассоциируются с конкретным пользователем во время каждого сеанса.
Как уже отмечалось выше, в НТТР отсутствуют стандартные механизмы идентификации пользователя, единственным постоянным элементом па протяжении сессии остается 1Р-адрес удаленного пользователя.
ВНИМАНИЕ
Сессия состоит из нескольких сеансов, производимых в ограниченный промежуток времени, на протяжении которых пользователь взаимодействует с сервером.
Но IР-адрес не является уникальным для каждого пользователя. Например в случае, когда используются прокси-серверы, IР-адрес пользователя будет определяться как адрес прокси-сервера. Если в одно и то же время на сервере, идентифицирующем пользователей по IР-адресу, будут находиться несколько пользователей, использующих один и тот же прокси-сервер, то такие пользователи будут идентифицироватся как один, поскольку имеют одинаковый IР-адрес.
Для того чтобы разделить пользователей, использующих один и тот же IР-адрес, требуется применить дополнительный механизм идентификации. Он заключается в создании уникального идентификатора сессии для каждого из пользователей и передаче его между сеансами.
Передача идентификатора сессии между сеансами может происходить как передача параметров строки запроса, каждая ссылка и форма па странице должны иметь этот параметр. Недостаток этого способа идентификации состоит в том, что при большом числе пользователей и генерируемых для каждого пользователя страниц загрузка сервера значительно повышается за счет обработки каждой ссылки и формы страницы.
ВНИМАНИЕ
Идентификатор сессии должен быть случайным для каждой новой сессии пользователя, это позволит избежать подбора идентификатора и подмены пользователя.
Другой способ состоит в использовании механизма Сооkies. Преимущества последнего очевидны — нет необходимости дополнять каждую ссылку и форму страницы параметром сессии, это снижает нагрузку и позволяет сохранять некоторые параметры между сессиями пользователя, вести статистику посещаемости конкретного пользователя и на основе его предпочтений предоставлять персонализированную информацию сразу, без проведения дополнительной авторизации. Однако, как и у всех методов идентификации, в данном случае есть свои минусы. Поддержка Соокies может быть отключена в большинстве используемых браузеров. Статистика свидетельствует, что на данный момент поддержку Сооkies отключают порядка 0,5 % пользователей Интернета, поэтому если Интернет-приложение должно обрабатывать всех пользователей, следует предусмотреть возможность обработки и таких запросов.