php сбросить все сессии
session_destroy
(PHP 4, PHP 5, PHP 7, PHP 8)
session_destroy — Уничтожает все данные сессии
Описание
При включённой опции session.use_strict_mode, вам не нужно удалять устаревшие cookie идентификатора сессии. В этом нет необходимости, потому что модуль сессии не примет cookie идентификатора сессии, если с этим идентификатором сессии нет связанных данных, и модуль сессии установит новый cookie идентификатора сессии. Рекомендуется включать опцию session.use_strict_mode для всех сайтов.
Немедленное удаление сессии может привести к нежелательным последствиям. При наличии конкурирующих запросов, другие соединения могут столкнуться с внезапной потерей данных сессии, например, это могут быть запросы от JavaScript и/или запросы из ссылок URL.
Даже если текущий модуль сессии не поддерживает пустые cookie идентификатора сессии, немедленное удаление сессии может привести к пустым cookie идентификатора сессии из-за состояния гонки на стороне клиента (браузера). Это приведёт к тому, что клиент создаст множество идентификаторов сессии без необходимости.
Список параметров
У этой функции нет параметров.
Возвращаемые значения
Возвращает true в случае успешного выполнения или false в случае возникновения ошибки.
Примеры
// Инициализируем сессию.
// Если вы используете session_name(«something»), не забудьте добавить это перед session_start()!
session_start ();
// Удаляем все переменные сессии.
$_SESSION = array();
// Наконец, уничтожаем сессию.
session_destroy ();
?>
Примечания
Как удалять сессию на сайте php!?
Всё об удалении сессии в php
Удаление определенной сессии при перезагрузке!
Для понимания, как удалить определенную сессию, нам понадобится:
Пример удаления сессии при перезагрузке
Скачать данный пример удаления сессии при перезагрузке.
Процесс удаления определенной сессии
Наша определенная сессия будет выглядеть так:
Разрушить/удалить определённую сессию можно несколькими способами:
Один из вариантов использовать unset
Иногда по неизвестным причинам функция unset отказывается работать! Тогда можно воспользоваться таким способом:
В самом верху страницы мы должны запустить сессию :
Создаем условие, в первой части проверяем есть ли сессия PRIMER, если существует, то удаляем сессию, и длаее, если сессия удалена выводим результат в удаления сессии в переменную.
Результат удаления определенной сессии будет выведен ниже в html коде с помощью echo
И собственно, как будет удаляться сессия при перезагрузке!?
Как только вы зайдете на страницу с данным скриптом, то сессия будет автоматически удалена, если она существует, на что и будет выведен результат!
Соберем весь код удаления определенной сессии:
Скачать данный пример удаления сессии при перезагрузке.
Как удалить сессию по клику.
Мы возьмем приведенный пример выше и всего лишь чуть его модернизируем!
Как и раньше, чтобы разобраться, нам для данного параграфа понадобится!
Этот же пример в архиве на странице всех скриптов.
Как работает удаление сессии по клику.
Как и ранее запускаем сессии :
Условие первой линии, если сессия существует, то внутри расположим условие второй линии:
Иначе(else) первой линии:
Условие второй линии(внутри первого если(if))
Иначе(else) второй линии, сработает в том случае, если сессия все еще существует, но кнопка удалить не нажата!
Выводим кнопку удалить сессию!
Соберем весь код вместе:
$rezult = ‘Нельзя удалить то, что не существует! Нужно создать сессию’;
Этот код в архиве на странице всех скриптов.
Как удалить все существующие сессии!?
Как удалить вообще все сессии, которые сейчас существуют для этого сайта!? :
Для реализации заголовка нашего параграфа мы просто возьмем код из предыдущего пункта, и вместо
Единственное в скрипт добавил
Сообщение системы комментирования :
Форма пока доступна только админу. скоро все заработает. надеюсь.
Сессии в PHP
С помощью сессии PHP сервер идентифицирует вас и позволяет выполнять необходимые операции: изменение информации на различных веб-страницах, добавление новой информации и т.д. После завершения работы на сайте вы удаляете текущую сессию, нажав на кнопку « Выйти »:
Что такое сессии в PHP?
Сессия PHP представляет собой способ хранения информации в переменных сессии, которые могут быть использованы для аутентификации на нескольких веб-страницах. В отличие от куков, информация сессии не хранится на компьютере пользователя. Вместо этого сессия создает файл на сервере во временном каталоге.
При создании PHP-сессии выполняются следующие три действия:
Эти установки помогают скрипту PHP извлекать из файла значения переменных сессии. На стороне клиента PHPSESSID содержит идентификатор сессии. Он подтверждает имя файла, который нужно искать в определенном каталоге на стороне сервера, из него переменные сессии могут быть извлечены и использованы для проверки.
Синтаксис сессий в PHP
Операции сессии
Результат : в результате запуска приведенного выше PHP-кода на сервере будет выведено следующее сообщение:
Результат : когда мы запустим на сервере приведенный выше PHP код, мы получим следующее сообщение. В нем будет приведен массив переменных сессии с их новыми значениями:
Заключение
Пожалуйста, оставьте ваши мнения по текущей теме статьи. За комментарии, лайки, отклики, дизлайки, подписки низкий вам поклон!
PHP cессии
Введение
HTTP протокол сам по себе stateless.
Сессии нужны для хранения информации о пользователях. Они используют cookie делают примерно то же что и cookies но лишены большинства их недостатков
Сессии это инструмент для управления состоянием приложения.
У каждой сессии есть уникальный номер Session ID или SID
Сессия должна быть начата до отправки данных браузеру.
Данные на сервере и куки в браузере работают в связке. SID хранится в куки.
Сервер «помнит» пользователя пока работа с сайтом ведётся в сессии.
Сессия удаляется автоматически при закрытии браузера. рассмотрим эти задачи в следующем параграфе
Что можно сделать с помощью сессий
Пример
Из обычной жизни: когда вы получаете счёт за электричество, там содержится много разной информации. Но чтобы оплатить его, нужен только номер счёта. Вводите номер счёта и всё остальное подтянется с сервера.
Пример запроса от клиента
Request 1 GET /homepage.php HTTP/1.1 Host: urn.su Accept: */*
Рекомендуется отпрвлять Session ID с сервера в виде куки. Другой вариант: Session ID можно передать в URL параметре.
Response 1 HTTP/1.1 200 OK Content-type: text/html Set-Cookie: SID
Запрос к другой странице будет уже с SID
Request 2 GET /aboutus.php HTTP/1.1 Host: urn.su Cookie: SID Accept: */*
Примерно таким образом куки позволяют запоминать пользовательские настройки
Где настраивать сессии
Настроек более 40, способов их задавать тоже несколько.
С помощью php.ini можно изменить настройки для всего PHP сервера.
Session Configurations Options
Полный список доступен на http://php.net
session.auto_start: автоматически начинает сессию.
По умолчанию выключена.
session.name: задаёт имя текущей сессии и сессионной куки
По умолчанию PHPSESSID.
session.save_path: путь по которому сохраняется информация о сессии
По умолчанию tmp директория сервера.
session.gc_maxlifetime: максимальное время жизни
По умолчанию 1440 секунд (24 минуты).
session.cookie_lifetime: время жизни куки, которая отправляется браузеру. По сути это значение, которое мы добавляем к time() когда задаём expires
Если включить то куки будут отправляться только по HTTPS.
По умолчанию выключена.
session.use_strict_mode: если включить то SID которые созданы не сервером будут отклонены.
По умолчанию выключена.
Если включить куки будет доступна только по HTTP (и HTTPS). То есть JavaScript или bbscript не смогут получить к куки доступ
По умолчанию выключена.
session.use_cookies: указывает нужно ли сохранять SID в cookies на стороне клиента.
По умолчанию включена.
session.use_only_cookies: заставляет сессию использовать только cookie для хранения SID. Работает совместно с session.use_cookies
По умолчанию включена.
session.use_trans_sid: контролирует использование «прозрачных» SID
Эту опцию обычно включают только тогда, когда нет поддержки cookies
По умолчанию выключена.
Пользуйтесь trans sid с осторожностью так как это может поставить под угрозу безопасность пользователя.
session.cache_limiter: указывает способ контроля за кэшем во время сессии.
По умолчанию nocache.
Для сессий с аутентификацией нужно, чтобы кэширование в браузере было отключено.
session.cookie_samesite: контролирует доступности куки в кроссдоменных запросах.
Доступные варианты: Lax и Strict
Кросдоменные запросы могу быть не только от злоумышленников. Их может делать ваш сайт с разных поддоменов. Либо вы можете следить за перемешением пользователя между своими проектами.
Функции
Полный список доступен на php.net
session_start(): начинает сессию и делает доступной переменную $_SESSION.
session_name(): переименовывает сессию.
Меняет значение, заданное с помощью функции session.name.
session_id(): получает или устанавливает текущий session id
set new session ID: session_id(‘ ‘)
session_destroy(): удаляет всю информацию записанную в сессию
Настройки вашего сервера могут отличаться, это просто пример
Инициализация сессии
Эта функция должна быть включена во все скрипты, в которых вам нужно использовать сессии.
Сохраняет данные в супер глобальной переменной $_SESSION, которая является массивом
Демонстрацию работы session_start() в вашем браузере вы можете сделать на этой странице
Посмотреть куки можно в Chrome DevTools → Application → Cookies
Выберите andreyolegovich.ru или urn.su и найдите AOSESSID
Изучить файл с данными о сессии можно в директории, которую вы указали в php_value session.save_path
Поэтому я смотрю содержимое там
Удаление сессии
Сессия истекает когда закрывается браузер, наступает таймаут, её явно делают просроченной.
Уничтожение сессии включает в себя:
session_destroy()
Удаляет все данные привязанные к сессии.
Не удаляет никаких переменных из суперглобальной переменной $_SESSION.
Если использовать только session_destroy() можно переиспользовать $_SESSION просто вызвав session_start()
unset()
unset() это стандартная PHP функция, которую использую не только с сессиями.
Чтобы очистить username нужно выполнить
unset ($_SESSION[ ‘username’ ]);
Чтобы очистить всё можно обойтись без unset()
Пример полного удалёния сессии
Подводные камни использования сессий в PHP
Приветствую, уважаемое сообщество.
Прежде всего, хочу поблагодарить за очень полезный ресурс. Не раз находил здесь множество интересных идей и практических советов.
Цель этой статьи — осветить подводные камни использования сессий в PHP. Конечно, есть документация по PHP и масса примеров, и данная статья не претендует на полное руководство. Она призвана раскрыть некоторые ньюансы работы с сессиями и оградить разработчиков от ненужной траты времени.
Самым распространенным примером использования сессий является, конечно, авторизация пользователей. Начнем с самой базовой реализации, чтобы последовательно развивать ее по мере появления новых задач.
(В целях экономии места и времени ограничимся в примерах только самими функциями работы с сессиями, вместо того, чтобы строить здесь полноценное тестовое приложение с красивой иерархией классов, исчерпывающей обработкой ошибок и прочими правильными штуками).
Примечание: Подразумевается, что базовые знания о сессиях PHP у читателя имеются, поэтому принцип работы функций session_start() и session_destroy() освещать здесь не будем. Задачи верстки формы входа и аутентификации пользователя не относятся к теме статьи, поэтому их мы также опустим. Напомню только, что для идентификации пользователя в каждом последующем запросе, нам необходимо в момент успешного входа сохранить в сессионной переменной (с именем userid, например) идентификатор пользователя, который будет доступен во всех последующих запросах в пределах жизни сессии. Также необходимо реализовать обработку результата нашей функции startSession(). Если функция вернула FALSE — отобразить в браузере форму входа. Если функция вернула TRUE, и сессионная переменная, содержащая идентификатор авторизованного пользователя (в нашем случае — userid), существует — отобразить страницу авторизованного пользователя (подробнее об обработке ошибок см. дополнение от 2013-06-07 в разделе о сессионных переменных).
Пока все понятно. Вопросы начинаются, когда требуется реализовать контроль отсутствия активности пользователя (session timeout), дать возможность одновременной работы в одном браузере нескольких пользователей, а также защитить сессии от несанкционированного использования. Об этом и пойдет речь ниже.
Контроль отсутствия активности пользователя встроенными средствами PHP
Первый вопрос, который часто возникает у разработчиков всевозможных консолей для пользователей — автоматическое завершение сеанса в случае отсутствия активности со стороны пользователя. Нет ничего проще, чем сделать это с помощью встроенных возможностей PHP. (Этот вариант не отличается особой надежностью и гибкостью, но рассмотрим его для полноты картины).
Немного пояснений. Как известно, PHP определяет, какую именно сессию нужно запустить, по имени куки, передаваемом браузером в заголовке запроса. Браузер же, в свою очередь, получает этот куки от сервера, куда помещает его функция session_start(). Если время жизни куки в браузере истекло, он не будет передан в запросе, а значит PHP не сможет определить, какую сессию нужно запустить, и расценит это как создание новой сессии. Параметр настроек PHP session.gc_maxlifetime, который устанавливается равным нашему таймауту отсутствия активности пользователя, задает время жизни PHP-сессии и контролируется сервером. Работает контроль времени жизни сессии следующим образом (здесь рассматривается пример хранилища сессий во временных файлах как самый распространенный и установленный по умолчанию в PHP вариант).
Примечание: Здесь следует отметить, что параметр session.gc_maxlifetime действует на все сессии в пределах одного сервера (точнее, в пределах одного главного процесса PHP). На практике это значит, что если на сервере работает несколько сайтов, и каждый из них имеет собственный таймаут отсутствия активности пользователей, то установка этого параметра на одном из сайтов приведет к его установке и для других сайтов. То же касается и shared-хостинга. Для избежания подобной ситуации используются отдельные каталоги сессий для каждого сайта в пределах одного сервера. Установка пути к каталогу сессий производится с помощью параметра session.save_path в файле настроек php.ini, или путем вызова функции ini_set(). После этого сессии каждого сайта будут храниться в отдельных каталогах, и параметр session.gc_maxlifetime, установленный на одном из сайтов, будет действовать только на его сессии. Мы не станем рассматривать этот случай подробно, тем более, что у нас в запасе есть более гибкий вариант контроля отсутствия активности пользователя.
Контроль отсутствия активности пользователя с помощью сессионных переменных
Казалось бы, предыдущий вариант при всей своей простоте (всего пару дополнительных строк кода) дает все, что нам нужно. Но что, если не каждый запрос можно расценивать как результат активности пользователя? Например, на странице установлен таймер, который периодически выполняет AJAX-запрос на получение обновлений от сервера. Такой запрос нельзя расценивать как активность пользователя, а значит автоматическое продление времени жизни сессии является не корректным в данном случае. Но мы знаем, что PHP обновляет время модификации файла сессии автоматически при каждом вызове функции session_start(), а значит любой запрос приведет к продлению времени жизни сессии, и таймаут отсутствия активности пользователя не наступит никогда. К тому же, последнее примечание из предыдущего раздела о тонкостях работы параметра session.gc_maxlifetime может показаться кому-то слишком запутанным и сложным в реализации.
Для решения этой проблемы откажемся от использования встроенных механизмов PHP и введем несколько новых сессионных переменных, которые позволят нам контролировать время отсутствия активности пользователей самостоятельно.
Обработка результата функции sessionStart()
В комментариях обратили внимание на то, что возврат FALSE не дает полного понимания причины ошибки, и это абсолютно справедливо. Я не стал публиковать здесь подробную обработку ошибок (объем статьи и так не маленький), поскольку это не относится напрямую к теме статьи. Но учитывая комментарии, внесу ясность.
Как видно, функция sessionStart может вернуть FALSE в двух случаях. Либо сессию не удалось запустить из-за каких-то внутренних ошибок сервера (например, неправильные настройки сессий в php.ini), либо время жизни сессии истекло. В первом случае мы должны перебросить пользователя на страницу с ошибкой о том, что есть проблемы на сервере, и формой обращения в службу поддержки. Во втором случае мы должны перевести пользователя на форму входа и вывести в ней соответствующее сообщение о том, что время сессии истекло. Для этого нам необходимо ввести коды ошибок и возвращать вместо FALSE соответствующий код, а в вызывающем методе проверять его и действовать соответствующим образом.
Теперь, даже если сессия на сервере по-прежнему существует, она будет уничтожена при первом же обращении к ней, если таймаут отсутствия активности пользователя истек. И это произойдет независимо от того, какое время жизни сессий установлено в глобальных настройках PHP.
Примечание: А что произойдет, если браузер был закрыт, и куки с именем сессии был автоматически уничтожен? Запрос к серверу при следующем открытии браузера не будет содержать куки сессии, и сервер не сможет открыть сессию и проверить таймаут отсутствия активности пользователя. Для нас это равносильно созданию новой сессии и никак не влияет на функционал и безопасность. Но возникает справедливый вопрос — а кто же тогда уничтожит старую сессию, если до сих пор ее уничтожали мы по истечении таймаута? Или она теперь будет висеть в каталоге сессий вечно? Для очистки старых сессий в PHP существует механизм под названием garbage collection. Он запускается в момент очередного запроса к серверу и чистит все старые сессии на основании даты последнего изменения файлов сессий. Но запуск механизма garbage collection происходит не при каждом запросе к серверу. Частота (а точнее, вероятность) запуска определяется двумя параметрами настроек session.gc_probability и session.gc_divisor. Результат от деления первого параметра на второй и есть вероятностью запуска механизма garbage collection. Таким образом, для того, чтобы механизм очистки сессий запускался при каждом запросе к севреру, эти параметры нужно установить в равные значения, например «1». Такой подход гарантирует чистоту каталога сессий, но, очевидно, является слишком накладным для сервера. Поэтому в production-системах по умолчанию устанавливается значение session.gc_divisor, равное 1000, что означает, что механизм garbage collection будет запускаться с вероятностью 1/1000. Если вы поэкспериментируете с этими настройками в своем файле php.ini, то сможете заметить, что в описанном выше случае, когда браузер закрывается и очищает все свои куки, в каталоге сессий какое-то время все еще остаются старые сессии. Но это не должно вас волновать, т.к. как уже было сказано, это ни коим образом не влияет на безопасность нашего механизма.
Предотвращение зависания скриптов из-за блокировки файла сессии
В комментариях подняли вопрос о зависании одновременно выполняющихся скриптов из-за блокировки файла сессии (как самый яркий вариант — long poll).
Для начала отмечу, что эта проблема напрямую не зависит от загруженности сервера или количества пользователей. Конечно, чем больше запросов, тем медленнее выполняются скрипты. Но это коссвенная зависимость. Проблема появляется только в пределах одной сессии, когда серверу приходит несколько запросов от имени одного пользователя (например, один из них long poll, а остальные — обычные запросы). Каждый запрос пытается получить доступ к одному и тому же файлу сессии, и если предыдущий запрос не разблокировал файл, то последующий будет висеть в ожидании.
Для сведения блокировки файлов сессий к минимуму настоятельно рекомендуется закрывать сессию путем вызова функции session_write_close() сразу после того, как выполнены все действия с сессионными переменными. На практике это означает, что не следует хранить в сессионных переменных все подряд и обращаться к ним на всем протяжении выполнения скрипта. А если и надо хранить в сессионных переменных какие-то рабочие данные, то считывать их сразу при старте сессии, сохранять в локальные переменные для последующего использования и закрывать сессию (имеется ввиду закрытие сессии с помощью функции session_write_close, а не уничтожение с помощью session_destroy).
В нашем примере это означает, что сразу после открытия сессии, проверки времени ее жизни и существования авторизованного пользователя, мы должны считать и сохранить все дополнительные необходимые приложению сессионные переменные (если такие существуют), после чего закрыть сессию с помощью вызова session_write_close() и продолжить выполнение скрипта, будь то long poll или обычный запрос.
Защита сессий от несанкционированного использования
Представим себе ситуацию. Один из ваших пользователей цепляет троян, который грабит куки браузера (в котором хранится наша сессия) и отправляет его на указанный email. Злоумышленник получает куки и использует его для подделки запроса от имени нашего авторизованного пользователя. Сервер успешно принимает и обрабатывает этот запрос, как если бы он пришел от авторизованного пользователя. Если не реализована дополнительная проверка IP-адреса, такая атака приведет к успешному взлому аккаунта пользователя со всеми вытекающими последствиями.
Почему это стало возможным? Очевидно, потому что имя и идентификатор сессии всегда одни и те же на все время жизни сессии, и если получить эти данные, то можно беспрепятственно слать запросы от имени другого пользователя (естественно, в пределах времени жизни этой сессии). Возможно, это не самый распространенный вид атак, но теоретически все выглядит вполне реализуемым, особенно учитывая, что подобному трояну даже не нужны права администратора, чтобы грабить куки браузера пользователя.
Как же можно защититься от атак подобного рода? Опять-таки, очевидно, ограничив время жизни идентификатора сессии и периодически изменяя идентификатор в пределах одной сессии. Мы можем также изменять и имя сессии, полностью удаляя старую и создавая новую сессию, копируя в нее все сессионные переменные из старой. Но на суть подхода это не влияет, поэтому для простоты ограничимся только идентификатором сессии.
Понятно, что чем меньше время жизни идентификатора сессии, тем меньше будет времени у злоумышленника, чтобы получить и применить куки для подделки запроса пользователя. В идеальном случае для каждого запроса должен использоваться новый идентификатор, что позволит свести к минимуму возможность использования чужой сессии. Но мы рассмотрим общий случай, когда время регенерации идентификатора сессии устанавливается произвольно.
(Опустим ту часть кода, которая уже рассмотрена).
Итак, при создании новой сессии (которое происходит в момент успешного входа пользователя), мы устанавливаем сессионную переменную starttime, хранящую для нас время последней генерации идентификатора сессии, в значение, равное текущему времени сервера. Далее в каждом запросе мы проверяем, не прошло ли достаточно времени (idLifetime) с момента последней генерации идентификатора, и если прошло — генерируем новый. Таким образом, если в течение установленного времени жизни идентификатора злоумышленник, получивший куки авторизованного пользователя, не успеет им воспользоваться, поддельный запрос будет расценен сервером как неавторизованный, и злоумышленник попадет на страницу входа.
Примечание: Новый идентификатор сессии попадает в куки браузера при вызове функции session_regenerate_id(), которая отправляет новый куки, аналогично функции session_start(), поэтому нам нет необходимости обновлять куки самостоятельно.
Если мы хотим максимально обезопасить наши сессии, достаточно установить время жизни идентификатора в единицу или же вообще вынести функцию session_regenerate_id() за скобки и убрать все проверки, что приведет к регенерации идентификатора в каждом запросе. (Я не проверял влияние такого подхода на быстродействие, и могу только сказать, что функция session_regenerate_id(true) выполняет по сути всего 4 действия: генерация нового идентификатора, создание заголовка с куки сессии, удаление старого и создание нового файла сессии).
Лирическое отступление: Если троян окажется настолько умным, что не будет отправлять куки злоумышленнику, а сам организует отправку заранее подготовленного поддельного запроса сразу при получении куки, описанный выше метод, скорее всего, не сможет защитить от подобной атаки, потому что между временем получения трояном куки и отправкой поддельного запроса практически не будет разницы, и велика вероятность, что в этот момент не произойдет регенерации идентификатора сессии.
Возможность одновременной работы в одном браузере от имени нескольких пользователей
Последняя задача, которую хотелось бы рассмотреть — возможность одновременной работы в одном браузере нескольких пользователей. Эта возможность особенно полезна на этапе тестирования, когда нужно эмулировать одновременную работу пользователей, и желательно делать это в своем любимом браузере, а не использовать весь доступный арсенал или открывать несколько экземпляров браузера в режиме «инкогнито».
В наших предыдущих примерах мы не задавали явно имя сессии, поэтому использовалось имя, установленное в PHP по умолчанию (PHPSESSID). Это значит, что все сессии, которые создавались нами до сих пор, отправляли браузеру куки под именем PHPSESSID. Очевидно, что если имя куки всегда одинаковое, то нет возможности в пределах одного браузера организовать две сессии с одинаковым именем. Но если бы мы для каждого пользователя использовали собственное имя сессии, то проблема была бы решена. Так и сделаем.
Теперь осталось позаботиться о том, чтобы вызывающий скрипт передавал в функцию startSession() уникальный префикс для каждого пользователя. Это можно сделать, например, через передачу префикса в GET/POST параметрах каждого запроса или через дополнительный куки.
Заключение
В заключение приведу полный конечный код наших функций для работы с сессиями PHP, включающий все рассмотренные выше задачи.
Надеюсь, эта статья сэкономит немного времени тем, кто никогда особо не углублялся в механизм сессий, и даст достаточно понимания этого механизма тем, кто только начинает знакомиться с PHP.