Cookie-файлы и сеансы

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

Механизмы сеансов, cookies и другие подобные механизмы (например, с серверной стороны) понадобились, поскольку изначально каждое HTTP-взаимодействие (запрос клиента – ответ сервера) было спроектировано как отдельное автономное TCP/IP-соединение (взаимодействие завершено – соединение разорвано), и такое взаимодействие не могло оставлять «следов» для последующих HTTP-взаимодействий.

Cookies

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

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

На рисунке ниже показано, где сохраняются cookies, когда веб-браузер запрашивает страницы; в данном примере сначала вызывается страница https://example.com/set.php, а затем страница https://example.com/read.php. После посещения первой страницы фактическое значение сохраняется в браузере клиента. Когда клиент запрашивает вторую страницу, вместе с запросом на сервер передается и cookie:

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

Использование функции setcookie()

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

Давайте рассмотрим пример:

setcookie('membername', 'Alex');

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

setcookie('membername', 'Alex', time() + 60 * 60 * 24 * 7, 
     "/", "www.mysite.com", 1);

В этом примере устанавливается cookie-файл со значением 'Alex'. Если бы на предыдущей странице был установлен cookie-файл, как показано в приведенном выше примере, то выполнение последнего оператора привело бы к его перезаписи. Срок хранения установлен равным 604 800 секундам (или 1 неделя) от текущей даты. В качестве параметра с обозначением пути задан самый верхний каталог в иерархии каталогов из всех возможных (/), поэтому данный cookie-файл может считываться в любом случае, независимо от его местонахождения в иерархии каталогов веб. Параметр с обозначением хоста задан равным "www.mysite.com". Это означает, что переход к просмотру следующей страницы должен привести к считыванию данного cookie-файла только в том случае, если пользователь действительно передает свой запрос с этого хоста. Наконец, последний параметр указывает, что рассматриваемый cookie-файл должен считываться или записываться через защищенное соединение между сокетами. (Если же само соединение, используемое на текущей странице, не является защищенным, то, по-видимому, данный cookie-файл вообще не будет установлен.)

Если требуется задать значения только последних параметров функции setcookie() и оставить первые не тронутыми, с тем чтобы им были присвоены значения, предусмотренные по умолчанию, то лучше все задать в качестве параметра с обозначением домена пустую строку (''), вместо параметра с обозначением пути ввести строку, содержащую символ косой черты ('/'), а в качестве срока хранения указать значение 0.

Если в сценарии PHP имеется несколько вызовов функции setcookie(), то такие вызовы обычно выполняются в последовательности, противоположной той, в которой они присутствуют в сценарии; но такая последовательность выполнения в некоторых версиях браузера нарушается. Лучше всего руководствоваться следующим правилом: никогда не передавать два разных значения для одного и того же cookie-файла при выполнении кода любой отдельно взятой страницы. (Так или иначе, передача больше чем одного cookie-файла не имеет смысла, поскольку один из них всегда перезаписывает другой.)

Cookie-файлы и проблемы защиты

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

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

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

Удаление cookie-файлов

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

Чтение cookie-файлов

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

• В версии PHP 4.1 и последующих версиях пара "имя-значение" из считанного cookie-файла добавляется к суперглобальному массиву $_COOKIE так, как если бы была выполнена операция $_COOKIE['name'] = value.

• Если разрешено использование директивы register_globals, то значение cookie-файла присваивается обычной глобальной переменной уровня страницы, имеющей такое же имя, как и в cookie-файле. Но поскольку использование директивы register_globals запрещено по умолчанию начиная с версии PHP 4.2, такая возможность в указанной или более поздней версии обеспечивается, только если администратор сервера внес изменение в конфигурацию.

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

$membername = $_COOKIE['membername'];
echo "Привет, <b>$membername</b>!";

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

Сеансы

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

Сеансы (sessions) позволяют разрешить эту проблему, обеспечивая поддержку данных между страницами на протяжении всего времени посещения пользователем вашего сайта. В рамках каждого сеанса могут быть задействованы многие переменные, которые будут храниться на протяжении всего сеанса. Сервер следит за сеансами пользователей, назначая им уникальные идентификаторы, которые генерируются сервером в момент открытия сеанса. Этот идентификатор называется идентификатором сеанса (session identifier) и должен передаваться на сервер каждый раз, когда после начала сеанса запрашивается очередная страница.

Рисунок ниже иллюстрирует порядок взаимодействий между браузером клиента и веб-сервером в рамках сеанса:

Информация о сеансах хранится на стороне сервера. Переменные сеанса сохраняются в файле, в сериализованном виде. Когда переменная сериализуется (преобразуется в последовательную форму), в файл записывается имя переменной, тип и значение в виде последовательной строки. В UNIX-подобных операционных системах этот файл обычно сохраняется в файловой системе /tmp (временная файловая система).

Интерпретатор PHP фактически не создает запись о сеансе, пока переменной сеанса не будет присвоено значение. Таким образом, при отсутствии каких-либо значений сеанс в действительности ничего не делает.

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

Необходимость в использовании средств поддержки сеансов

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

• К проекту сайта предъявляется требование, чтобы по мере прохождения пользователя от одной страницы к другой содержимое страниц, развертываемых в браузере, изменялось в зависимости от того, какие страницы уже посетил пользователь (или от количества просмотренных страниц).

• Требуется, чтобы в окне браузера пользователя отображались рекламные объявления, но каждое конкретное объявление не должно появляться больше одного раза в течение каждого сеанса.

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

• Необходимо в целом проследить за тем, как пользователи перемещаются по страницам сайта, например, узнать, как они обычно переходят на ту или иную внутреннюю страницу, — ставят на ней закладку или всегда проходят весь путь от начальной страницы?

Использование сеансов

Чтобы начать сеанс, нужно добавить в начало PHP-сценария вызов функции session_start() – лишь после этого появится возможность сохранять и получать данные, принадлежащие сеансу. Функцию session_start() следует вызвать до вызова функции header() и вообще до того, как браузеру клиента будет отправлена хоть какая-нибудь информация, в противном случае сеанс может работать некорректно.

Обращение к переменным сеанса заключается в использовании суперглобальной переменной $_SESSION с подстановкой имени требуемой переменной в квадратных скобках. В примере ниже показан простой счетчик просмотра страницы за один сеанс (для простоты этот пример основан на обновлении одной и той же страницы несколько раз, однако, ни что не ограничивает вас в применении сеансов на нескольких страницах, но не забывайте добавлять на каждую из них вызов метода session_start()):

<?php
    session_start();
?>
<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8">
<title>Основы PHP</title>
</head>

<body>

<?php 
	
if (!isset($_SESSION['count_view']))
{
	echo '<h1>Вы в первый раз посещаете данную страницу.</h1>';
	$_SESSION['count_view'] = 1;
}
else
{
	++$_SESSION['count_view'];
	echo '<h1>Количество посещений вами этой страницы за 1 сеанс: '
	    .$_SESSION['count_view'].'</h1>';
}

?>

</body>
</html>

Завершение сеанса

Есть моменты, когда требуется преждевременно завершить сеанс. Например, если вы разместили на странице кнопку или гиперссылку выхода из системы. Выход из системы фактически означает завершение сеанса работы с пользователем. Завершают сеанс с помощью функции session_destroy(). Разумеется, сеанс предварительно должен быть открыт, чтобы было что завершать.

Имейте в виду: завершение сеанса не означает, что его переменные станут недоступными для текущего PHP-сценария. В примере ниже приведен простой сценарий, который закрывает сеанс, делая при этом его переменные недоступными для остальной части PHP-сценария:

<?php
session_start();

// Выполнить какие-либо действия в рамках сеанса
$_SESSION['username'] = 'Alex';

// Завершить сеанс работы с сайтом
session_destroy();

echo "В этот момент мы все еще можем увидеть значение имени пользователя: "
     .$_SESSION['username']."<br>";

// Уничтожить значение в массиве $_SESSION
unset($_SESSION['username']);

if (empty($_SESSION['username'])) 
{
    echo "Теперь переменная \$_SESSION['username'] является пустой";
}
?>

Результат работы сценария из примера приведен на рисунке:

При закрытии сеанса его данные удаляются из файлов на стороне сервера. Чтобы удалить переменные сеанса, необходимо присвоить пустой массив суперглобальной переменной $_SESSION.

Сборка мусора

Теперь займемся сборкой мусора – нет, речь не о том, что пора браться за швабру; имеется в виду процедура сборки мусора по завершении сеанса или по истечении предельного времени ожидания.

Сборка мусора (garbage collection) – это то, что должно произойти с содержимым сеанса на стороне сервера после завершения сеанса или по достижении предельного времени отсутствия активности. Если сервер не будет периодически удалять информацию о старых сеансах, она будет накапливаться до бесконечности, занимая дисковое пространство и мешая работе сервера. Сборка мусора производится автоматически, при выполнении этой операции удаляются все данные устаревших сеансов.

В PHP можно регулировать нагрузку на механизм сборки мусора, чтобы не удалять старые файлы сеансов при каждом обращении к сеансу. По умолчанию предельное время жизни файлов сеанса составляет 1440 с, или 24 мин. Для очень надежных сайтов это время не слишком велико, однако в PHP есть ряд параметров, управляющих удалением мусора. Файл сеанса может быть удален по истечении заданного интервала времени, но он может продолжать свое существование на диске сервера и дольше – все зависит от количества созданных сеансов. В файле инициализации PHP (php.ini) отношение к сборке мусора имеют следующие параметры:

• session.gc_maxlifetime (значение по умолчанию 1440);

• session.gc_probability (значение по умолчанию 1);

• session.gc_divisor (значение по умолчанию 100).

В этих переменных символы gc означают garbage collector (сборщик мусора). Если у вас на сервере достаточно дискового пространства, можно увеличить предельное время ожидания, чтобы предотвратить завершение большинства или даже всех сеансов до закрытия браузера. Однако во многих случаях требуется ограничить предельную продолжительность сеанса – этого можно добиться, изменив срок хранения cookie.

Чтобы определить, пора ли запускать сборщик мусора, интерпретатор PHP генерирует случайное число в диапазоне от 0 до 1. Если полученное число меньше, чем дробная часть отношения session.gc_probability / session.gc_divisor, запускается сборщик мусора. Рассмотрим настройку предельного времени продолжительности сеанса подробнее, чтобы вы лучше поняли необходимые действия.

Настройка предельного времени продолжительности сеанса

По истечении определенного времени вполне разумно было бы автоматически закрыть сеанс пользователя – в этом и состоит понятие предельного времени ожидания. PHP позволяет задать эту продолжительность. Лучший способ – изменить содержимое файла .htaccess. Файл .htaccess воздействует на HTML- и PHP-файлы, расположенные в том же каталоге. Это позволяет изменять настройки, не меняя содержимое файлов настройки веб-сервера Apache. Любые изменения в файле .htaccess будут применяться к файлам в подкаталогах, если в них отсутствуют собственные файлы .htaccess.

В примере ниже мы изменили предельное время продолжительности сеанса с помощью параметра session.gc_maxlifetime:

<IfModule mod_php4.c>
    php_value session.gc_maxlifetime "14400"
</IfModule>

В параметре session.gc_maxlifetime время задается в секундах, то есть если требуется установить предельное время продолжительности сеанса равным 30 мин, следует подставить значение 1800. Кроме того, можно изменить это значение прямо из PHP-сценария:

<?php
    ini_set("session.gc_maxlifetime", "14400");
?>

Данный фрагмент также устанавливает предельное время ожидания в 14 400 с.

Функции поддержки сеанса

Выше мы описали две наиболее часто используемые PHP-функции для работы с сеансами - session_start() и session_destroy(). В таблице ниже приведены остальные функции, относящиеся к сеансам, с описанием назначения каждой из них. Обратите внимание на то, что в некоторых случаях результаты выполнения рассматриваемых функций зависят от значений параметров конфигурации:

Передача заголовков HTTP

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

Синтаксическая конструкция вызова функции header() предельно проста: эта функция принимает единственный строковый параметр, который представляет собой передаваемый заголовок.

Пример использования заголовка для перенаправления

Одним из наиболее удобных заголовков, передаваемых по протоколу HTTP, является заголовок Location: который может действовать в качестве редиректа (средства перенаправления). Для его использования достаточно поместить полностью уточненный URL после строки "Location: ", и браузер возобновит свою работу, обратившись к новому адресу вместо существующего. Соответствующий пример кода приведен ниже:

<?php
    header("Location: https://google.com");
?>
<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8">
<title>Основы PHP</title>
</head>

<body>
Вы не увидите этот текст
</body>
</html>

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