Поиск

Более сложные методы работы с файлами cookie

Основы работы с файлами cookie довольно просты. Сервер передает броузеру пакет cookie, а позже броузер возвращает его назад серверу. Хотя, конечно, существуют нюансы. Например, можно увеличить время жизни (или срок действия) файлов cookie, а также сделать его бесконечно большим. Такие файлы cookie называются перманентными. Их параметры можно задать так, чтобы они возвращались только по конкретному URL. (Данная настройка означает применение определенного уровня безопасности.)

Сохранение файлов cookie

Все рассматриваемые нами до сих пор файлы cookie временно хранились в броузере: как только броузер завершал свою работу, файлы cookie автоматически удалялись. Использование временных файлов cookie вместо скрытых полей HTML-форм для передачи данных между несколькими формами вполне приемлемо. При новом запуске броузера вы вряд ли захотите использовать старый файл cookie, оставшийся от предыдущего сеанса работы с сервером, поскольку пользователь должен будет заново заполнить все поля многостраничной формы.

В некоторых случаях возникает необходимость в постоянном хранении файлов cookie (речь идет о нескольких дня, неделях или даже месяцах). С помощью модуля CGi в среде Perl создание таких файлов не составляет труда.

Чтобы установить дату истечения срока действия файла cookie, при его создании нужно использовать аргумент -expires. За ним должна следовать дата, определяющая конец срока действия файла cookie. Эту дату можно указать в нескольких форматах, как показано в табл. 21.1.

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

Следующая небольшая программа устанавливает в броузере файл cookie, срок действия которого истекает через восемь дней:

А теперь поговорим немного о грустном

В мире нет ничего постоянного. В том числе и постоянно действующих файлов cookie. Например, если ваша CGI-программа отправит броузеру некоторый пакет cookie, не следует полагать, что он будет активен в течение заданного (с момента установки) количества недель, месяцев или лет.

Как будет отмечено ниже, в разделе "Проблемы с файлами cookie" броузеры не обязаны хранить файлы cookie. На самом деле они вообще не обязаны их принимать, причем вы даже не будете уведомлены о том, что файл cookie не принят.

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

Пользователи могут случайно или намеренно удалить файлы cookie. Если пользователь устанавливает новую версию броузера или операционной системы, файлы cookie могут быть попросту затерты или оказаться "не в том месте". Иногда файлы cookie исчезают даже при запуске другого броузера. Когда броузер неактивен, пакеты cookie обычно хранятся в файле, который пользователи могут легко отредактировать, удалить или испортить.

Следовательно, хранение ценной информации в файлах cookie нельзя назвать удачной идеей. Любая информация, которую, казалось бы, стоило постоянно сохранять в пакете cookie, может быть легко заменена, удалена или испорчена. Речь идет о пользовательских параметрах настройки, именах и паролях, предназначенных для регистрации на Web-сервере, различного рода служебной информации, времени последнего посещения и др.

Если хотите знать, то большинство броузеров, находясь в неактивном состоянии, хранят пакеты cookie в обычных текстовых файлах, поэтому их можно легко просмотреть с помощью любого текстового редактора. Броузер Netscape хранит пакеты cookie в файле cookies.txt, расположенном в рабочем каталоге пользователя, который в разных операционных системах имеет разное имя. Броузер Internet Explorer хранит файлы cookie в каталоге \Windows\Cookies.
Отправка файлов cookie другим серверам

Файлы cookie по умолчанию отправляются обратно только тому серверу, который их прислал. Иногда такая оправка пакетов cookie "по обратному адресу" отвечает вашему желанию, а иногда — совсем нет. Например, рассмотрим некоторый вымышленный Web-сервер congo.com, который предназначен для продажи книг. На нем работают два виртуальных Web-узла: www.congo.com и shopping.congo.com (рис. 21.3). Основной Web-узел (с адресом www.congo.com) содержит всю информацию о компании, гиперссылки на другие узлы и, что более важно, гиперссылки на электронный книжный магазин.

Web-узел www.congo.com содержит HTML-форму для регистрации и обрабатьшающую ее данные CGI-программу. С их помощью пользователь может внести свое имя в списки почтовой рассылки и сообщить серверу о том, какие книги его интересуют. Позже, при посещении узла www.congo.com, пользователь может прочитать о новых книгах, список которых составляется с учетом его интересов. Эта информация хранится в файлах cookie, полученных с узла www.congo.com и установленных в броузере пользователя (рис. 21.4).

Проблема состоит в том, что, когда пользователь от узла www.congo.com переходит к электронному магазину по адресу shopping.congo.com, файлы cookie не отправляются серверу с адресом shopping.congo.com. Файлы cookie возвращаются только тому серверу, от которого они были получены. Если пакет cookie был послан с адреса www.congo.com, то он не возвратится по адресу shopping.congo.com.

Так что же делать? Совершенно неприемлемо заставлять пользователя заполнять другую форму и отправлять ему новый cookie с сервера shopping.congo.com. Есть выход получше. Можно ограничить действие файла cookie конкретным именем домена. Например, когда с сервера www.congo.com посылается оригинальный пакет cookie, можно создать условия, при которых этот пакет мог бы отправиться к любому Web-узлу домена congo.com, как показано на рис. 21.5.

Эта технология реализуется на этапе создания пакета cookie с помощью аргумента -domain функции cookie:

В приведенном выше фрагменте создается пакет cookie с именем preferences, действие которого ограничивается доменом congo.com. Теперь броузер сможет возвратить этот cookie любому Web-серверу, имя которого оканчивается на congo.com.

Аргумент для задания домена должен иметь по крайней мере две части. Он не может являться доменом верхнего уровня, т.е. представлять собой имена .com или .net. Это сделано для того, чтобы броузер не передавал один и тот же пакет cookie всем серверам домена верхнего уровня.
Создание персональных пакетов cookie

Можно также ограничить область действия пакетов cookie заданной CGI-программой. По умолчанию после создания пакета cookie он будет возвращаться данному серверу по любому запрошенному броузером URL, включая URL, не содержащие CGI-программы. Рассмотрим, например, автомобильный Web-узел, схема которого показана на рис. 21.6.

Имеет смысл размещать CGI-программы, связанные с отделом продаж, отдельно от CGI-программ производственного подразделения. Если бы сбытовая CGI-программа установила пакет cookie, то этот же пакет отправлялся бы и производственной CGI-программе, и наоборот. Такое положение вещей, конечно же, нежелательно, и создателям CGI-программ, предназначенных для обоих узлов, пришлось бы предпринять меры по координации действий во избежание конфликта по имени файлов cookie.

Чтобы обойти эту проблему, можно использовать аргумент -path функции cookie. С его помощью указывается путь (относящийся к URL верхнего уровня), по которому пакет cookie должен вернуться. Например, чтобы отправить пакет cookie, который будет возвращаться только к сбытовой CGI-программе, можно использовать следующий фрагмент кода:

По умолчанию файлы cookie возвращаются каждому узлу сервера, как если бы был использован параметр -path=>'/'. Для ограничения "области распространения" пакета cookie, т.е. чтобы он возвращался только заданной CGI-программе, в аргументе -path указывается URL CGI-программы.

Вы должны помнить из материала предыдущего занятия, что функция script_name модуля CGI возвращает часть адреса URL текущей CGI-программы. С ее помощью можно быстро создать пакет cookie, который будет возвращаться только программе, установившей этот cookie в броузере.

Безопасность пакетов cookie

Для передачи некоторых пакетов cookie может потребоваться установить безопасное соединение с сервером. Используя аргумент -secure функции cookie, можно организовать оправку пакетов cookie с броузера только в том случае, если соединение является безопасным. С помощью следующего фрагмента программы организуется отправка броузеру номера счета пользователя. Пакет cookie, содержащий подобную информацию, должен передаваться только через безопасное соединение.

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

Однако для установления факта безопасного соединения не следует слишком уж полагаться на этот метод. Не стоит также рассчитывать и на точность используемого номера счета. Помните, что именно пользователь управляет Web-броузером и его файлами cookie. He исключено, что пакет cookie, содержащий закрытую информацию, может быть отправлен серверу через обычное (а не безопасное) соединение, да и номер счета может оказаться неверным.