Меню Рубрики

Установка времени сессии php

Настройка времени сессий в PHP

От времени действия сессии зависит период работоспособности PHP-переменных $_SESSION, и как следствие, активности веб-приложений. Например, если пользователь авторизовался в системе, время в течении которого он может бездействовать без необходимости повторного ввода логина и пароля зависит от данного параметра.

Существуют разные способы установки времени жизни сессий. Попробуем разобраться на примере операционной системы Linux.

Как узнать время жизни сессии

Перед настройкой, стоит посмотреть текущее состояние. Есть несколько методов это сделать:

1. На сервере командой php

Получаем список параметров, имеющих отношение к сессиям. Нас интересуют:

  • session.cookie_lifetime => 0 => 0
  • session.gc_maxlifetime => 1440 => 1440

Данные значения — значение по умолчанию. cookie_lifetime => 0 говорит о действии файлов куки до закрытия браузера, если задать этому параметру определенное значение, сессия будет прерываться при активном сеансе, поэтому лучше ее оставлять в значении ноль.

2. C помощью php-функции ini_get

Настройка сессий на веб-сервере

Выполняется путем настройки файла php.ini. Данный способ удобен, если мы являемся администратором веб-сервера, а также если есть гарантия, что общая настройка сессий не повлияет на работоспособность всех веб-приложений, работающих на данном сервере.

Открываем на редактирование php.ini:

И редактируем следующие параметры:

session.gc_maxlifetime = 86400
session.cookie_lifetime = 0

* где параметр gc_maxlifetime указывает на временя в секундах, после прошествии которого данные могут быть удалены; cookie_lifetime — время жизни файлов cookies; 86400 — 24 часа в секундах.
* если параметру gc_maxlifetime задать значение 0, действие сессий будет бесконечным. Это, как правило, не стоит делать — приведет к падению производительности и безопасности сервера.

Путь до php.ini может быть разный в зависимости от программной платформы и набора компонентов. Например, при использовании php-fpm, путь может быть следующий: /etc/php/7.1/fpm/php.ini. Узнать путь можно командой php -i | grep php.ini

После настройки параметров, необходимо перезагрузить сервер, являющийся интерпретатором PHP.

systemctl restart apache2 || systemctl restart httpd

* в версиях Linux без systemd используем команду service apache2 restart или service httpd restart.

Если используем FastCGI (PHP-FPM):

systemctl restart php-fpm || service php-fpm restart

Настройка через файл .htaccess

Данный файл позволяет веб-мастеру управлять некоторыми настройками веб-сервера. Для его редактирования нужен доступ к файлам сайта. Способ не сработает, если в качестве обработчика PHP используется не Apache, а, например, NGINX + PHP-FPM. Хотя, тут тоже есть способ (о нем будет ниже).

В файл .htaccess вносим следующее:

php_value session.gc_maxlifetime 86400
php_value session.cookie_lifetime 0

* как можно заметить, параметры те же, что при настройки через php.ini.

Как говорилось выше, метод не сработает, если не используется Apache. Однако настройку можно выполнить на сервере (опять же, у нас должен быть соответствующий доступ).

Открываем файл настройки веб-сервера, например, в php-fpm:

php_value[session.gc_maxlifetime] = 86400
php_value[session.cookie_lifetime] = 0

После перезапускаем сервис:

systemctl restart php-fpm || service php-fpm restart

Задание параметра в коде приложения

Способ может быть полезен, когда разные страницы портала должны иметь разное время жизни сессии. Для этого можно воспользоваться PHP-функциями ini_set и session_set_cookie_params, например:

Функции обязательно вызывать до открытия сесии (session_start).

Установка сессии в приложении

Некоторые приложения могут переопределять настройки. В таком случае, задать время жизни сессии необходимо в параметрах программы. У каждого приложения свои настройки, в которых необходимо самостоятельно разобраться. Приведем для примера настройку сессии в CMS Битрикс.

Заходим в Группы пользователей — выбираем группу — Безопасность. Находим параметр «Время жизни сессии (минут)» и ставим время, например 1440 (24 часа в минутах).

Как автоматически продлевать сессии

Если сессия выдается на определенный период и заканчивается в определенное время, это может привести к прерыванию активного сеанса пользователя. Гораздо удобнее, если время действия сессии будет автоматически продлеваться, если посетитель обновляет страницу. Для этого существует параметр cookie_lifetime, который во всех примерах выше мы задавали в значении 0.

Если мы зададим значение cookie_lifetime 86400, то через 24 часа сессия прервется. Это не всегда удобно.

Если есть необходимость в контроле и прерывании сессии, можно воспользоваться php-функцией session_destroy().

Путь хранения файлов сессий

Место хранения файлов сессий задается параметром session.save_path также, так время жизни. По умолчанию, может использоваться путь /var/lib/php/sessions.

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

источник

PHP — работа с сессиями

Здравствуйте, уважаемые читатели блога LifeExample, сегодня хочу затронуть одну несложную тему и в тоже время очень полезную любому PHP проекту. Поговорим о том, как осуществляется работа с сессиями в PHP.

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

Созданный для пользователя, текстовый файл актуален вплоть до ухода его с сайта, поэтому и называется сессией.

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

Как работать с сессиями PHP

Чтобы создать сессию необходимо в коде формирования страницы, до любого вывода контента, вызвать функцию:

Данная функция создаст новый файл на сервере для хранения данных пользователя и выдаст ему идентификатор session_id, или откроет его актуальную сессию по ранее созданному идентификатору.

Сам идентификатор будет сохранен в куках пользователя в его браузере, обычно в похожем виде:

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

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

Пример для работы с сессиями в PHP

В приведенном коде если активен флаг $fillSession, то сессия заполняется определенными данными, заметьте, что типы данных могут быть самыми разнообразными – строки, числа, массивы, значения возвращаемые функциями.

Попробуйте запустить этот код на странице – он не выведет вам ничего. Затем присвойте $fillSession = true и обновите страницу, вы увидите содержание массива $_SESSION.

Теперь верните $fillSession = false, и снова обновите страницу.

Массив наполнился и теперь хранит в себе информацию. Вы даже можете закрыть браузер и снова открыть страницу, как видите — данные сохранились!

Храниться одни будут пока не истечет установленное время сессии или вы лично не уничтожите сессию функцией:

Время жизни сессии в PHP

Время жизни сессии в PHP можно задать несколькими способами:

1. Явно задать количество секунд хранения файлов сессий в коде PHP:

2. Задать значения для директив в php.ini:

3. Использовать файл .htaccess:

Для чего можно использовать сессии

В PHP работа с сессиями часто сопровождается задачей – сохранения данных авторизованного на сайте пользователя. Но помимо этого в сессии можно хранить флаги определенных действий, которые совершил или не совершил пользователь, находясь на вашем сайте, например:

  • Авторизовался;
  • Побывал на конкретной странице;
  • Ничего не делал в течение какого-либо периода времени;
  • Уже посмотрел всплывающее окно с рекламой;

Также сессия подходит для хранения информации пользователя, например:

  • Имя, фамилия, отчество;
  • Корзина покупателя;
  • Реферальный хост, откуда пришел пользователь;
  • Временные данные;

Опасные моменты

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

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

Перечень всех функций для работы с сессиями

Изучив следующие стандартные методы php, работа с сессиями… будет вам в радость :-). Шучу, на самом деле следующий список приведен только ради полноты информации, но по большому счету кроме session_start(); и session_destroy(); вам редко что-то понадобится.

В данной статье “php работа с сессиями” я попробовал познакомить вас с основами программирования и привел практический пример. Надеюсь вам было понятно. 😉

Читайте также похожие статьи:

Чтобы не пропустить публикацию следующей статьи подписывайтесь на рассылку по E-mail или RSS ленту блога.

источник

Работа с сессиями в PHP

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

Что такое сессия PHP?

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

Эта информация, хранимая на протяжении сессии, доступна для всех веб-страниц ресурса. На сервере расположение временного файла определяется параметром session.save_path в конфигурационном файле php.ini .

При создании PHP-сессии выполняются следующие три действия:

  • Когда создается сессия, PHP генерирует уникальный идентификатор, который представляет собой случайную строку из 32 шестнадцатеричных чисел. Идентификатор времени жизни сессии PHP выглядит примерно так: 9c8foj87c3jj973actop1re472e8774 ;
  • Сервер отправляет на компьютер пользователя куки, называемые PHPSESSID , для хранения строки уникального идентификатора сессии;
  • Сервер генерирует в указанном временном каталоге файл, который содержит имя уникального идентификатора сессии с префиксом sess _g. sess_9c8foj87c3jj973actop1re472e8774 .
Читайте также:  Установка акушерского пессария при беременности отзывы

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

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

Синтаксис сессий в PHP

При PHP авторизации через сессию она создается с помощью функции session_start() и удаляется с помощью функции session_destroy() . Глобальная переменная PHP , известная под именем $_SESSION , используется для установки значений переменных сессии. Сбросить все значения, установленные для переменных сессии, можно с помощью функции session_unset() .

Синтаксис Описание
session_start(); Это встроенная функция для создания PHP-сессии.
session_destroy(); Это встроенная функция позволяет удалить сессию PHP .
session_unset(); Это встроенная функция для сброса всех переменных сессии. Она запускается перед функцией session_destroy () .
isset (); Это встроенная функция для проверки, установлены ли переменные сессии или нет.
$_SESSION Это глобальная переменная PHP, которая используется для установки значений переменных сессии. Например, $_SESSION[“user >
print_r($_SESSION) Выводит полный массив переменных сессии и их значений.

Операции сессии

Мы рассмотрим следующие операции с использованием сессии PHP , а также их примеры.

  • Запуск сессии PHP и установка ее переменных сессии: новая сессия PHP запускается с помощью функции session_start() . После того, как сессия была создана, можно установить значения ее переменных сессии с помощью $_SESSION . Мы установили значения для переменных “ userID ” — “ php_user ” и “ password ” — “ tutorials ”:

Результат : в результате запуска приведенного выше PHP-кода на сервере будет выведено следующее сообщение:

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

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

  • Обновление значений переменных сессии PHP : Во время сессии можно обновить значения ее переменных. Сначала нам нужно открыть PHP-сессию в начале каждой страницы ( session_start () ). В приведенном ниже коде мы обновляем значения переменных “ userID ” — “ new_php_user ” и “ password ” — “ education ”.

Можно вывести массив переменных сессии и их значений с помощью функции print_r($ _SESSION) , как показано ниже:

Результат : когда мы запустим на сервере приведенный выше PHP код, мы получим следующее сообщение. В нем будет приведен массив переменных сессии с их новыми значениями:

  • Удаление сессии PHP и сброс всех значений переменных сессии: Можно сбросить сессию PHP с помощью функции session_unset() и удалить текущую сессию с помощью функции session_destroy() :

Результат: когда мы запустим на веб-сервере приведенный выше PHP-код , в результате он выведет следующее сообщение:

Заключение

В этой статье мы рассказали о различных функциях для работы с сессиями PHP , их синтаксисе. В отличие от куков, информация сессий хранится на стороне сервера. Благодаря этому сессии PHP более надежны.

Данная публикация представляет собой перевод статьи « Learn Working with Sessions in PHP » , подготовленной дружной командой проекта Интернет-технологии.ру

источник

PHP для начинающих. Сессия

Всем хорошего дня. Перед вами первая статья из серии PHP для начинающих разработчиков. Это будет необычная серия статей, тут не будет echo «Hello World» , тут будет hardcore из жизни PHP программистов с небольшой примесью «домашней работы» для закрепления материала.

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

Но для начала, чтобы понять зачем нам сессия, обратимся к истокам — к HTTP протоколу.

HTTP Protocol

Изначально подразумевали, что по этому протоколу будет только HTML передаваться, отсель и название, а сейчас чего только не отправляют и =^.^= и(•_ㅅ_•)

Чтобы не ходить вокруг да около, давайте я вам приведу пример общения по HTTP протоколу.
Вот пример запроса, каким его отправляет ваш браузер, когда вы запрашиваете страницу http://example.com :

Это очень упрощенные примеры, но и тут можно увидеть из чего состоят HTTP запрос и ответ:

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

Так, вроде с протоколом разобрались — он простой, ведёт свою историю аж с 1992-го года, так что идеальным его не назовешь, но какой есть — отправили запрос — получите ответ, и всё, сервер и клиент никоим образом более не связаны. Но подобный сценарий отнюдь не единственный возможный, у нас же может быть авторизация, сервер должен каким-то образом понимать, что вот этот запрос пришёл от определенного пользователя, т.е. клиент и сервер должны общаться в рамках некой сессии. И да, для этого придумали следующий механизм:

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

Для реализации этого механизма и были созданы cookie (куки, печеньки) — простые текстовые файлы на вашем компьютере, по файлу для каждого домена (хотя некоторые браузеры более продвинутые, и используют для хранения SQLite базу данных), при этом браузер накладывает ограничение на количество записей и размер хранимых данных (для большинства браузеров это 4096 байт, см. RFC 2109 от 1997-го года)

Т.е. если украсть cookie из вашего браузера, то можно будет зайти на вашу страничку в facebook от вашего имени? Не пугайтесь, так сделать нельзя, по крайней мере с facebook, и дальше я вам покажу один из возможных способов защиты от данного вида атаки на ваших пользователей.

Давайте теперь посмотрим как изменятся наши запрос-ответ, будь там авторизация:

Метод у нас изменился на POST, и в теле запроса у нас передаются логин и пароль. Если использовать метод GET, то строка запроса будет содержать логин и пароль, что не очень правильно с идеологической точки зрения, и имеет ряд побочных явлений в виде логирования (например, в том же access.log ) и кеширования паролей в открытом виде.

Ответ сервер будет содержать заголовок Set-Cookie: KEY=VerySecretUniqueKey , что заставит браузер сохранить эти данные в файлы cookie, и при следующем обращении к серверу — они будут отправлены и опознаны сервером:

Как можно заметить, заголовки отправляемые браузером (Request Headers) и сервером (Response Headers) отличаются, хотя есть и общие и для запросов и для ответов (General Headers)

Сервер узнал нашего пользователя по присланным cookie, и дальше предоставит ему доступ к личной информации. Так, ну вроде с сессиями и HTTP разобрались, теперь можно вернутся к PHP и его особенностям.

PHP и сессия

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

Вот вам статейка на тему PHP is meant to die, или вот она же на русском языке, но лучше отложите её в закладки «на потом».

Перво-наперво необходимо «стартовать» сессию — для этого воспользуемся функцией session_start(), создайте файл session.start.php со следующим содержимым:

Запустите встроенный в PHP web-server в папке с вашим скриптом:

Запустите браузер, и откройте в нём Developer Tools (или что там у вас), далее перейдите на страницу http://127.0.0.1:8080/session.start.php — вы должны увидеть лишь пустую страницу, но не спешите закрывать — посмотрите на заголовки которые нам прислал сервер:

Там будет много чего, интересует нас только вот эта строчка в ответе сервера (почистите куки, если нет такой строчки, и обновите страницу):

Увидев сие, браузер сохранит у себя куку с именем `PHPSESSID`:

PHPSESSID — имя сессии по умолчанию, регулируется из конфига php.ini директивой session.name, при необходимости имя можно изменить в самом конфигурационном файле или с помощью функции session_name()

И теперь — обновляем страничку, и видим, что браузер отправляет эту куку на сервер, можете попробовать пару раз обновить страницу, результат будет идентичным:

Итого, что мы имеем — теория совпала с практикой, и это просто отлично.

Следующий шаг — сохраним в сессию произвольное значение, для этого в PHP используется супер-глобальная переменная $_SESSION , сохранять будем текущее время — для этого вызовем функцию date():

Обновляем страничку и видим время сервера, обновляем ещё раз — и время обновилось. Давайте теперь сделаем так, чтобы установленное время не изменялось при каждом обновлении страницы:

Обновляем — время не меняется, то что нужно. Но при этом мы помним, PHP умирает, значит данную сессию он где-то хранит, и мы найдём это место…

Всё тайное становится явным

В вашей конфигурации путь к файлам может быть не указан, тогда файлы сессии будут хранится во временных файлах вашей системы — вызовите функцию sys_get_temp_dir() и узнайте где это потаённое место.

Так, идём по данному пути и находим ваш файл сессии (у меня это файл sess_dap83arr6r3b56e0q7t5i0qf91 ), откроем его в текстовом редакторе:

Читайте также:  Установка window 8 ключ продукта

Как видим — вот оно наше время, вот в каком хитром формате хранится наша сессия, но мы можем внести правки, поменять время, или можем просто вписать любую строку, почему бы и нет:

Для преобразования этой строки в массив нужно воспользоваться функцией session_decode(), для обратного преобразования — session_encode() — это зовется сериализацией, вот только в PHP для сессий — она своя — особенная, хотя можно использовать и стандартную PHP сериализацию — пропишите в конфигурационной директиве session.serialize_handler значение php_serialize и будет вам счастье, и $_SESSION можно будет использовать без ограничений — в качестве индекса теперь вы сможете использовать цифры и специальные символы | и ! в имени (за все 10+ лет работы, ни разу не надо было 🙂

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

Так, что мы ещё не пробовали? Правильно — украсть «печеньки», давайте запустим другой браузер и добавим в него теже самые cookie. Я вам для этого простенький javascript написал, скопируйте его в консоль браузера и запустите, только не забудьте идентификатор сессии поменять на свой:

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

Это подделать сложнее, но всё ещё возможно, добавьте сюда ещё сохранение и проверку $_SERVER[‘REMOTE_ADDR’] и $_SERVER[‘HTTP_X_FORWARDED_FOR’] , и это уже более-менее будет похоже на защиту от злоумышленников посягающих на наши «печеньки».

Ключевое слово в предыдущем абзаце похоже, в реальных проектах cookies уже давно «бегают» по HTTPS протоколу, таким образом никто их не сможет украсть без физического доступа к вашему компьютеру или смартфону

Стоит упомянуть директиву session.cookie-httponly, благодаря ей сессионная кука будет недоступна из JavaScript’a. Кроме этого — если заглянуть в мануал функции setcookie(), то можно заметить, что последний параметр так же отвечает за HttpOnly. Помните об этом — эта настройка позволяет достаточно эффективно бороться с XSS атаками в практически всех браузерах.

По шагам

А теперь поясню по шагам алгоритм, как работает сессия в PHP, на примере следующего кода (настройки по умолчанию):

  1. после вызова session_start() PHP ищет в cookie идентификатор сессии по имени прописанном в session.name — это PHPSESSID
  2. если нет идентификатора — то он создаётся (см. session_id()), и создаёт пустой файл сессии по пути session.save_path с именем sess_ , в ответ сервера будет добавлены заголовки, для установки cookie =
  3. если идентификатор присутствует, то ищем файл сессии в папке session.save_path :
    • не находим — создаём пустой файл с именем sess_ <$_COOKIE[session_name()]>(идентификатор может содержать лишь символы из диапазонов a-z , A-Z , 0-9 , запятую и знак минус)
    • находим, читаем файл и распаковываем данные (см. session_decode()) в супер-глобальную переменную $_SESSION (файл блокируется для чтения/записи)
  4. когда скрипт закончил свою работу, то все данные из $_SESSION запаковывают с использованием session_encode() в файл по пути session.save_path с именем sess_ (блокировка снимается)

А есть ли жизнь без «печенек»?

PHP может работать с сессией даже если cookie в браузере отключены, но тогда все URL на сайте будут содержать параметр с идентификатором вашей сессии, и да — это ещё настроить надо, но оно вам надо? Мне не приходилось это использовать, но если очень хочется — я просто скажу где копать:

А если надо сессию в базе данных хранить?

Отдельно замечу, что не надо писать собственные обработчики сессий для redis и memcache — когда вы устанавливаете данные расширения, то вместе с ними идут и соответствующие обработчики, так что RTFM наше всё. Ну и да, обработчик нужно указывать до вызова session_start() 😉

Когда умирает сессия?

За время жизни сессии отвечает директива session.gc_maxlifetime. По умолчанию, данная директива равна 1440 секундам (24 минуты), понимать её следует так, что если к сессии не было обращении в течении заданного времени, то сессия будет считаться «протухшей» и будет ждать своей очереди на удаление.

Интересен другой вопрос, можете задать его матёрым разработчикам — когда PHP удаляет файлы просроченных сессий? Ответ есть в официальном руководстве, но не в явном виде — так что запоминайте:

Сборщик мусора (garbage collection) может запускаться при вызове функции session_start() , вероятность запуска зависит от двух директив session.gc_probability и session.gc_divisor, первая выступает в качестве делимого, вторая — делителя, и по умолчанию эти значения 1 и 100, т.е. вероятность того, что сборщик будет запущен и файлы сессий будут удалены — примерно 1%.

Самая тривиальная ошибка

Ошибка у которой более полумиллиона результатов в выдаче Google:

Cannot send session cookie — headers already sent by
Cannot send session cache limiter — headers already sent

Для получения таковой, создайте файл session.error.php со следующим содержимым:

Во второй строке странная «магия» — это фокус с буфером вывода, я ещё расскажу о нём в одной из следующих статей, пока считайте это лишь строкой длинной в 4096 символов, в данном случае — это всё пробелы

Запустите, предварительно удалив cookie, и получите приведенные ошибки, хоть текст ошибок и разный, но суть одна — поезд ушёл — сервер уже отправил браузеру содержимое страницы, и отправлять заголовки уже поздно, это не сработает, и в куках не появилось заветного идентификатора сессии. Если вы стокнулись с данной ошибкой — ищите место, где выводится текст раньше времени, это может быть пробел до символов , или после ?> в одном из подключаемых файлов, и ладно если это пробел, может быть и какой-нить непечатный символ вроде BOM, так что будьте внимательны, и вас сия зараза не коснется (как-же,… гомерический смех).

Для проверки полученных знаний, я хочу, чтобы вы реализовали свой собственный механизм сессий и заставили приведенный код работать:

Блокировка

Ещё одна распространённая ошибка у новичков — это попытка прочитать файл сессии пока он заблокирован другим скриптом. Собственно, это не совсем ошибка, это недопонимание принципа блокировки 🙂

Но давайте ещё раз по шагам:

  1. session_start() не только создаёт/читает файл, но и блокирует его, чтобы никто не мог внести правки в момент выполнения скрипта, или прочитать не консистентные данные из файла сессии
  2. блокировка снимается по окончанию выполнения скрипта

«Воткнутся» в данную ошибку очень легко, создайте два файла:

Теперь, если вы откроете в браузере страничку lock.php , а затем в новой вкладке откроете start.php то увидите, что вторая страничка откроется только после того, как отработает первый скрипт, который блокирует файл сессии на 10 секунд.

Есть пару вариантов, как избежать подобного явления — «топорный» и «продуманный».

«Топорный»
Использовать самописный обработчик сессий, в котором «забыть» реализовать блокировку 🙂
Чуть лучше вариант, это взять готовый и отключить блокировку (например у memcached есть такая опция — memcached.sess_locking) O_o
Потратить часы на дебаг кода в поисках редко всплывающей ошибки…

«Продуманный»
Куда как лучше — самому следить за блокировкой сессии, и снимать её, когда она не требуется:

— Если вы уверенны, что вам не потребуется вносить изменения в сессионные данные используйте опцию read_and_close при старте сессии:

Таким образом, блокировка будет снята сразу по прочтению данных сессии.

— Если вам таки нужно вносить изменения в сессию, то после внесения оных закрывайте сессию от записи:

В заключение

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

P.S. Если узнали что-то новое из статьи — отблагодарите автора — зашарьте статью в социалках 😉
P.P.S. Да, это кросс-пост статьи с моего блога, но она актуальна и поныне 🙂

Серия статей «PHP для начинающих»:

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Несколько других советов для PHP-разработчиков

Ошибки начинающих PHP разработчиков

Как правильно объяснить начинающему php-программисту зачем, как и когда использовать ООП?

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 41

Нет, он лишь внешне смотрится просто. Один только RFC 2616 занимает 176 страниц, а более новые RFC 7230-7235 — все 305 страниц в сумме

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

Прокси-серверы по определению видят ВЕСЬ запрос, в том числе тело и куки. Сохранить, соответственно, тоже могут что угодно куда угодно. Если же запрос зашифрованный (https, vpn и т.п.), то они не смогут увидеть ни тела, ни кук, ни строку запроса тоже. Если имеется в виду кеширование GET-запросов, то это отключается средствами HTTP, а POST-запрос нужен совсем не поэтому

Не такой уж и Secret, если флагов HttpOnly и Secure нет (впрочем, ниже по тексту HttpOnly упоминается)

Язык PHP создавался под стать протоколу HTTP — т.е. основная его задача — это дать ответ на HTTP запрос и «умереть» освободив память и ресурсы. Следовательно, и механизм сессий работает в PHP не в автоматическом режиме, а в ручном, и нужно знать что вызвать, да в каком порядке.

Из первого предложения никак не следует второе

расскажу о способах защиты [. ] будем запоминать User-Agent

Вообще не защита. User-Agent не является секретом и подбирается на ура, особенно для популярных браузеров

То есть после выхода новой версии браузера пользователь больше не сможет пользоваться сайтом?

добавьте сюда ещё сохранение и проверку $_SERVER[‘REMOTE_ADDR’]

То есть пользователи мобильных сетей больше не смогут пользоваться сайтом?

Этот заголовок вообще может установить пользователь как хочет, и опираться на него без предварительной настройки сервера нельзя

это уже более-менее будет походить на защиту от злоумышленников

Это будет походить на защиту от обычных пользователей, которые всего лишь обновили свой хром из гугл-плея и/или перебежали в другой макдональдс и потеряли доступ к сайту

эта настройка [HttpOnly] позволяет достаточно эффективно бороться с XSS атаками в практически всех браузерах

HttpOnly не имеет вообще никакого отношения к XSS. Если есть XSS, то ничто не мешает напакостить и, например, отправлять ajax-запросы без и чтения кук (куки к запросам на тот же origin автоматически добавит сам браузер)

«Для начинающих» не означает, что можно писать что-то не соответствующее действительности. Ну или в крайнем случае можно для упрощения объяснений, но с обязательной припиской о неточности и ссылкой для интересующихся, где почитать подробнее

я хотел донести главное, что её нужно внедрять

Судя по качеству продемонстрированноый защиты — на этой мысли и стоило остановиться, а сейчас реализация из статьи лишь несёт вред

Тем не менее, обычно в access-логах сохраняется именно url, а не содержимое тела запроса.

Передавать логин с паролем нужно через POST не для защиты от перехвата трафика, а для защиты от подобного сохранения в логах. Чтобы не получилось, что в БД все пароли хранятся строго в виде хешей и все как бы безопасно — а рядом лежит файлик с теми же самыми паролями в открытом виде.

Прокси-серверы по определению видят ВЕСЬ запрос, в том числе тело и куки. Сохранить, соответственно, тоже могут что угодно куда угодно

Вот именно про access.log и нужно было рассказать в статье, а прокси вообще не упоминать

Текущая формулировка лучше изначальной. Но access.log всё равно лучше упомянуть, потому что, в отличие от туманного какого-то там «логирования и кеширования», файлы access.log начинающий сможет найти без труда на почти любом хостинге

Ответ есть в официальном руководстве, но не в явном виде

Вы в этом точно уверены? Не хотите проверить?

Если ваше утверждение верно, то через 10 секунд сессия прервется. Я же утверждаю что она будет вполне себе живой до следующего прохода сборщика мусора.

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

Я, конечно, давно не делал ничего с сессиями на PHP (да и вообще на PHP), но меня терзает смутное сомнение, что при выполнении session_start() браузеру отправляется директива не приводящая к созданию файловой куки. Сессионный идентификатор хранится только в памяти браузера и уничтожается при закрытии браузера.

А чтобы создать файловую куку, нужно выполнить команду setcookie, причем с установленным достаточно большим временем ее жизни. И в эту куку уже записывать ID сессии или/и «билет» входа (сессионный пароль).

Хотя… извиняюсь, если что попутал.

Да… в последнее время у некоторых браузеров даже сессионные куки хранятся в БД. Но речь не столько о способе хранения, сколько о продолжительности. Раньше различие было четко — сессионные куки не хранились на диске в виде файлов или в БД, а информация длительного хранения записывалась в файловые куки. С тех пор многое изменилось. Но суть в том, что по session_start() в браузер передается директива Set-Cookie без указания срока хранения этой информации (с нулевым сроком), т.е. краткосрочная. А для создания куки длительного хранения используется setcookie с указанием срока годности этой информации.

Т.е. — это механизмы для создания сессий разного срока действия.

Но… действительно все зависит от браузера. Говорят, Хром не удаляет id сессий с нулевым сроком жизни при закрытии. И они могут быть использованы повторно.

Ещё со времен РНР4 есть возможность задать $lifetime для сессионой куки
session_set_cookie_params ( int $lifetime [, string $path [, string $domain [, bool $secure = FALSE [, bool $httponly = FALSE ]]]] ) : bool

При изучении сессий в свое время очень долго тупил по некоторым моментам (описание ситуация из 2004 года, а не сегодняшние):

1. Не работают сессии. О ней вы немного рассказали — нельзя выводить текст в браузер до старта сессии. Вообще никакой ни из какого файла — если старт сессии происходит в подключенном файле (include), то по пути до самой этой функции старта сессии ничего не должно выводиться в браузер. Я долго спотыкался о display_errors — когда о всех notice и warning инфа выдается в браузер (пример):

Пример больше надуманный, но сессия стартовать не будет, так как прилетит notice о том, что в массиве $_GET нет индекса logout — это неявная на первый взгляд ситуация. Но сам будучи новичком — нервов попила эта ситуация — я же нигде echo не вызываю!?

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

3. Долго не мог понять, зачем вообще эти сессии помимо авторизации (разграничения доступа к определенному функционалу) — они ведь позволяют хранить вообще любые данные для конкретного пользователя на самом сервере, а не на клиенте. Но фишка как раз в том, что в сессии можно хранить данные, которые можно «передавать» между различными запросами, то есть что-то делал на одном шаге, сохранил состояние. Помню, что когда клепал каталог товаров с возможностью покупки, то хранил эти самые покупки в отдельном файлике — самописный функционал, файл назывался session_id.txt, то есть авторизацию проводил через сессию, а вот параметры хранил через свои костыли. До этого я просто не мог понять, читая статьи, что можно в сессиях хранить что-то больше, чем идентификатор. То есть для новичков пишут — хранить там можно все. А дальше нарисуй сову сам. А если бы объясняли на пальцах, что состояние корзины покупок мы можем хранить в массиве, который в свою очередь можем хранить в сессии и потом доставать из него штатными средствами php, чтобы решить задачу, а не изобретать костыли для ее решения.

4. Так же пояснять о том, что сессию «поднять» можно закрыв вкладку, но для этого нужно настроить куку, точнее ее время хранение и для какого домена (страниц) она должна отдаваться браузеру.

Я б не стал набирать комментарий, но вот кратко описал то, с чем столкнулся при изучении. Из статьи я тоже понял только то, что сессия позволяет распознавать пользователя на сайте. И все. Что там что-то можно хранить, но для чего это может понадобиться — не сказано. А если учитель привел бы конкретные примеры/ситуации или решение пусть того же to-do list через сессии — то есть завтра можно открыть вкладку и что-то дописать/отредактировать (потом как эту же задачу решить с помощью голого mysqli, затем как с помощью классов — PDO — тут же про иньекции и пр). Тут как раз можно было бы осветить большую часть возможностей, но уже вместе с практикой.

Отступление: еще в школьные годы, к бабушке-соседке приезжал внук: толковый парень, мог с механикой решить и аргументировать решение своей задачи — под каким углом срезать уголки, чтобы сварочный шов был крепче. По звуку мог определить с каким цилиндром что-то не то. И т. д. Но вот забить гвоздь не умел. Наточить нож тоже. Зато знал все в теории, потому что практика у него отсутствовала. Может не было мотивации, может еще что-то. Может он просто инженер-теоретик. Но суть мысли в другом — теория, закрепленная практикой — бесценна. Знания остаются в памяти более надолго.

Нужно знать для чего инструмент (сессия) — для решения каких задач — корзина покупателя, авторизация, передача параметров между запросами в пять дней между самими запросами и т.д. — а не просто вот вам есть такой инструмент. Бывают конечно и исключения из правил — синяя изолента и молоток с ломом, но это уже другая история.

Какое-то большое имхо получилось…

Статья неплохая получилась, но хотелось бы чуточку «для чего это нужно», а не просто сухой текст.

источник

Добавить комментарий

Adblock
detector