Файлы cookie
Использование сети таким образом, который мы только что описали, включает набор независимых запросов страниц. Отсутствует понятия сеанса связи. Браузер клиента посылает запрос на сервер и получает в ответ файл. После этого сервер забывает о том, что он когда-либо видел этого клиента.
Эта модель прекрасно подходит для получения документов, предназначенных для широкой публики, и она хорошо работала в то время, когда Всемирная паутина была только создана. Однако такой вариант не подходит для возвращения различных страниц разным пользователям в зависимости от того, что они уже сделали с сервером. Такое поведение необходимо для многих непрерывных взаимодействий с веб-сайтами. К примеру, на некоторых сайтах (например, сайтах газет) требуется регистрация пользователей; а иногда получение информации с сайта является платным. Возникает вопрос различения запросов от зарегистрированных пользователей и от всех остальных. Вторым примером является электронная коммерция. Как серверу собрать информацию о состоянии корзины пользователя, если тот время от времени пополняет ее содержимое? Третий пример — веб-порталы типа Yahoo!. Пользователям предоставляется возможность индивидуально настраивать вид начальной страницы (например, так, чтобы им сразу показывались последние новости о любимой спортивной команде или курсы ценных бумаг). Однако как сервер сможет корректно отобразить страницу, если он не знает, с каким пользователем имеет дело?
На первый взгляд может показаться, что решение очевидно: сервер может различать пользователей по их IP-адресам. Однако эта идея не работает. Во-первых, многие пользователи работают на компьютерах с разделяемыми ресурсами (например, дома), и с помощью IP-адреса можно идентифицировать лишь компьютер, а не пользователя. Что еще хуже, многие компании используют NAT, поэтому исходящие пакеты от всех клиентов имеют один и тот же IP-адрес. То есть все компьютеры, которые работают через NAT, кажутся серверу одинаковыми. К тому же многие ISP приписывают IP-адреса посетителям при помощи DHCP. IP-адрес со временем может измениться, так что для сервера вы внезапно станете выглядеть так же, как ваш сосед. По всем этим причинам сервер не может использовать IP-адрес, чтобы отслеживать пользователей.
Для решения этой проблемы был предложен сильно раскритикованный метод cookie-файлов. Такое название произошло от старинного программистского сленгового словечка. Программа вызывала процедуру и получала взамен нечто, что могло понадобиться впоследствии для выполнения какой-либо задачи. Это «нечто» и называлось cookie. В этом смысле файловый дескриптор в UNIX и дескриптор объектов в Windows можно рассматривать как cookie. Эти специальные маркеры были впервые применены в браузере Netscape в 1994 году. Сейчас они формализованы в RFC 2109.
Когда пользователь запрашивает страницу, сервер может снабдить свой ответ дополнительной информацией в форме cookie-файла, который представляет собой маленькую именованную строку (до 4 Кб), которую сервер может ассоциировать с браузером. Эта ассоциация не позволяет наверняка определить пользователя, но она является гораздо более точной, чем IP-адрес. Браузеры обычно на некоторое время сохраняют полученные маркеры в каталоге cookie на жестком диске клиента, так что cookie-файлы сохраняются при повторных вызовах браузера, если только пользователь не отключил данную функцию. Итак, cookie — это файлы или строки, а не исполняемые программы. В принципе, в них может содержаться вирус, но поскольку они рассматриваются всего лишь как информационные данные, нет какой-либо официальной возможности для активации вирусов и нанесения ущерба системе. Однако у хакера всегда есть возможность, используя ошибки в браузере, заставить активироваться вирусы, содержащиеся в cookie.
В маркерах cookie может содержаться до пяти полей, как показано в табл. 7.10. Поле Домен (Domain) содержит имя домена, с которого пришел маркер. Предполагается, что браузеры проверяют тот факт, что серверы не лгут относительно имен доменов. Каждый домен должен хранить не более 20 маркеров, связанных с одним клиентом. Поле Путь (Path) содержит путь в структуре каталогов на сервере, указывающий те части дерева каталогов, которые могут использовать маркер. Часто в этом поле содержится знак «/», означающий, что доступно дерево целиком.
Поле Содержимое (Content) имеет вид имя = значение. Как имя, так и значение могут быть совершенно произвольными, на усмотрение сервера. В этом поле хранится основная информация, которую несет в себе маркер.
Поле Годен до (Expires) указывает срок годности маркера. Если это поле отсутствует, браузер отбрасывает cookie сразу после выхода из программы. Такой маркер называется непостоянным (nonpersistent cookie). Если же указано время и дата, то о таком маркере говорят, что он постоянный (persistent cookie). Он хранится до тех пор, пока не выйдет срок годности. Время, указываемое в поле Годен до, — гринвичское. Чтобы удалить cookie с жесткого диска клиента, сервер просто посылает его заново, указывая вышедший срок годности.
Таблица 7.10. Несколько примеров cookie
Наконец, поле Защищенный (Secure) может быть установлено для индикации того, что браузер может вернуть его только на сервер, использующий защищенный канал передачи информации, а именно SSL/TLS (который мы опишем в главе 8). Это свойство используется в электронной коммерции, банковском деле и других приложениях, в которых важна защита информации.
Итак, мы узнали о получении маркеров. Как же они используются? Непосредственно перед отправкой браузером запроса на получение страницы на какой-нибудь веб-сайт проверяется каталог с cookie. Ищутся маркеры, пришедшие с того (и только того) домена, на который отправляется запрос. Все найденные маркеры отправляются вместе с запросом. Получив их, сервер может интерпретировать содержащуюся в них информацию так, как ему нужно.
Рассмотрим возможные применения cookie. В табл. 7.10 первый cookie был прислан доменом toms-casino.com и используется для идентификации клиента. Если через неделю тот же клиент возвращается на сайт, чтобы просадить очередную сумму денег, браузер отправляет cookie, так что сервер узнает старого знакомого. Вооружившись идентификатором пользователя, сервер может найти запись о нем в базе данных и использовать эту информацию для генерации соответствующей веб-страницы. В зависимости от азартности игрока ему может быть предложен покер, таблица результатов сегодняшних скачек или просто игровой автомат.
Второй cookie-маркер пришел сjills-store.com. Сценарий в этом случае заключается в том, что клиент бродит по магазину, выбирая себе покупки. Найдя что-нибудь привлекательное, он щелкает на значке товара. При этом сервер добавляет товар к списку покупок (который поддерживается на сервере), а также создает cookie-маркер, содержащий код заказанного товара, и отсылает cookie клиенту. Клиент продолжает бродить по электронному магазину, щелкая мышью на новых страницах, и в ответ на каждый новый запрос страницы на сервер отсылается cookie. По мере накопления выбранных товаров дополняется информация в cookie. Наконец, когда пользователь щелкает ПЕРЕЙТИ К РАСЧЕТАМ, cookie, содержащий теперь уже полную информацию о покупках, отсылается вместе с запросом на сервер. Таким образом, серверу точно известно, какие товары хочет приобрести клиент.
Третий cookie-маркер прибыл с веб-портала. Когда пользователь щелкает по ссылке на портал, браузер отсылает ему cookie, в котором говорится о том, что надо показать страницу, содержащую котировки акций Cisco и Oracle, а также результаты футбольного матча New York Jets. Так как максимальный размер cookie-файла равен 4 Кб, то остается еще много места для более детальной настройки страницы. Например, в нее можно включить сводку погоды, специальные предложения, заголовки статей в крупных газетах и т. п.
