Сессии в php

Другие функции для работы с сессиями

session_unregister(string) — сессия забывает значение заданной глобальной переменной;session_destroy() — сессия уничтожается (например, если пользователь покинул систему, нажав кнопку выход);session_set_cookie_params(int lifetime ]) — с помощью этой функции можно установить, как долго будет жить сессия, задав unix_timestamp определяющий время смерти сессии.

Список функций для работы с сессиями (session) в phpsession_cache_expire — возвращает окончание действия текущего кэша session_cache_limiter — получает и/или устанавливает текущий ограничитель кэша session_commit — псевдоним session_write_close() session_decode — декодирует данные сессии из строки session_destroy — уничтожает все данные, зарегистрированные для сессии session_encode — шифрует данные текущей сессии как строку session_get_cookie_params — получает параметры куки сессии session_id — получает и/или устанавливает текущий session id session_is_registered — определяет, зарегистрирована ли переменная в сессии session_module_name — получает и/или устанавливает модуль текущей сессии session_name — получает и/или устанавливает имя текущей сессии session_regenerate_id — модифицирует текущий идентификатор сеанса недавно сгенерированным session_register — регистрирует одну или более переменных для текущей сессии session_save_path — получает и/или устанавливает путь сохранения текущей сессии session_set_cookie_params — устанавливает параметры куки сессии session_set_save_handler — устанавливает функции хранения сессии уровня пользователя session_start — инициализирует данные сессии session_unregister — дерегистрирует переменную из текущей сессии session_unset — освобождает все переменные сессии session_write_close — записывает данные сессии и конец сессии

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

Взаимодействие с сессией

Получение данных

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

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

Глобальный помощник

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

Определение наличия элемента в сессии

Чтобы определить, присутствует ли элемент в сессии, вы можете использовать метод . Метод возвращает , если элемент присутствует, и не равен :

Чтобы определить, присутствует ли элемент в сессии, даже если его значение равно , то вы можете использовать метод :

Сохранение данных

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

Добавление в массив значений сессии

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

Увеличение и уменьшение отдельных значений в сессии

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

Кратковременные данные

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

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

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

Пересоздание идентификатора сессии

Пересоздание идентификатора сессии часто выполняется для предотвращения использования злоумышленниками атаки, называемой фиксацией сессии, на ваше приложение.

Laravel автоматически пересоздает идентификатор сессии во время аутентификации, если вы используете один из стартовых комплектов приложений Laravel или Laravel Fortify; однако, если вам необходимо вручную повторно сгенерировать идентификатор сессии, то вы можете использовать метод :

Если вам нужно повторно сгенерировать идентификатор сессии и удалить все данные из нее одним выражением, то вы можете использовать метод :

Cookies

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

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

Как установить куки: функция setcookie

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

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

За установку куки в PHP отвечает функция , ей нужно передать как минимум три параметра, описанных выше. Пример:

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

Как прочитать куки

В PHP максимально упрощён процесс чтения информации из кукисов. Все переданные сервером куки становятся автоматически доступны в специальном глобальном массиве
Так, чтобы получить содержимое куки с именем «visit_count», достаточно обратиться к одноимённому элементу массива , например вот так:

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

Собираем всё вместе

Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:

Решение

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

Путь сеанса PHP — это место, где данные сеанса хранятся на вашем сервере, а не на клиенте. Смотрите документацию:

Вы можете переместить эти файлы и заменить / сохранить в случае коллизий, как считаете нужным. Это в значительной степени ограничено только правами на чтение / запись, которые есть у вас при доступе / перемещении материала, и у вашего пользователя веб-сервера (например, apache или nginx) или php-пользователя есть право на чтение / запись их из / в новое место.

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

изменить на основе вашего обновленного вопроса:

Там уже есть хорошее решение на основе JS для истечения срока действия старого cookie. Я бы пошел с этим. если вы не можете просто сделать это, вы можете сделать перенаправление на там есть php-скрипт, который читает куки и где-то хранит данные (например, базу данных на основе user_id) и истекает куки. Затем вы можете перенаправить на старую страницу, найти «/» — cookie и восстановить данные. Это очень уродливый хак, но я не думаю, что вы можете получить cookie для каждого пути в PHP, так как он на стороне сервера и основан на идентификаторе сеанса, предоставленном клиентом (но я могу ошибаться).

16

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

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

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

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

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

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

Расположение временного файла определяется настройкой в файле php.ini в директиве .

Пример использования в файле php.ini:

session.save_path = «/var/www/my_site/data/tmp»

Изменить директорию для хранения файлов сессий можно добавив в файл .htaccess:

php_value session.save_path «/var/www/my_site/data/tmp»

Перед использованием любой переменной сеанса убедитесь, что вы установили этот путь.

Когда сессия стартует, происходит следующее:

• Сначала PHP создает уникальный идентификатор для этой конкретной сессии, который представляет собой случайную строку из 32 шестнадцатеричных чисел, например 5c9foj24c3jj973hjkop2fc937e3463.

• Файл cookie под названием автоматически отправляется на компьютер пользователя для хранения уникальной строки идентификации сессии.

• Файл автоматически создается на сервере в назначенном временном каталоге и имеет имя уникального идентификатора с префиксом sess_, т.е. sess_5c9foj24c3jj973hjkop2fc937e3463.

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

С помощью специальных функций мы можем получить данный идентификатор:

echo session_id(); // идентификатор сессии
echo session_name(); // имя — PHPSESSID

То же значение мы могли бы получить, обратившись к cookie напрямую:

echo $_COOKIE;

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

Создание защищенных страниц

Главной целью механизма сессий является создание защищенных страниц. Простой сценарий PHP, приведенный ниже, позволяет защитить изображения от публичного доступа. Файл сценария protectedimage.php вызывает функцию require_once(‘status.php’) в самом начале. С помощью нее происходит однократное исполнение сценария проверки состояния. Сценарий проверки состояния проверяет работоспособность сессии и позволяет выполнение последующих функций в случае действительной сессии, либо прекращает работу сценария в ином случае. Код для защиты изображения показан ниже:

<?php
/*protectedimage.php*/
require_once(‘status.php’);
print(«<div align=»center»><img src=»summer.jpg» width=75%></div>»);
?>

Защищенное изображение, которое выводится после корректного открытия сессии, показано на Рисунке 6, а на Рисунке 7 показана та же самая страница (http://127.0.0.1/protectedimage.php), загруженная без предварительного открытия сессии. Посмотрите на URL в адресной строке браузера на обоих рисунках — страница с одним и тем же URL содержит картинку в случае доступных данных сессии и запрещает доступ к картинке если данные сессии недоступны.

Рисунок 6: Картинка является защищенным содержимым страницы

Рисунок 7: Доступ к защищенному содержимому страницы запрещен если данные сессии недоступны

Примеры TempData

Рассмотрим следующую страницу, которая создает клиент:

На следующей странице отображается :

В предыдущей разметке в конце запроса не удаляется, так как используется . На обновляемой странице отображается .

Следующая разметка похожа на приведенный выше код, но в ней используется для сохранения данных в конце запроса:

При переходе между страницами IndexPeek и IndexKeep не удаляется.

Следующий код отображает , но в конце запроса удаляется:

Поставщики TempData

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

Данные файлов cookie шифруются с помощью IDataProtector с кодировкой с использованием Base64UrlTextEncoder и последующей фрагментацией. Так как файл cookie фрагментируется, ограничение на размер одного такого файла cookie, заданное в ASP.NET Core 1.x, не применяется. Данные файла cookie не сжимаются, так как сжатие зашифрованных данных может привести к проблемам с безопасностью, например атакам CRIME и BREACH. Дополнительные сведения о поставщике TempData, основанном на файлах cookie, см. здесь: CookieTempDataProvider.

Выбор поставщика TempData

Выбор поставщика TempData включает в себя несколько аспектов:

1. Приложение уже использует состояние сеанса? Если это так, использование поставщика TempData для состояния сеанса не требует от приложения никаких дополнительных издержек (кроме объема данных).
2. Приложение использует TempData лишь ограниченно, для сравнительно небольших объемов данных (до 500 байт)? Если это так, поставщик TempData на основе файлов cookie незначительно увеличивает издержки для каждого запроса, переносящего TempData. В противном случае поставщик TempData для состояния сеанса удобно использовать, чтобы устранить круговой обход большого объема данных в каждом запросе до полного использования TempData.
3. Приложение выполняется на ферме серверов на нескольких серверах? Если это так, не требуется дополнительная настройка для использования поставщика TempData для файлов cookie, за исключением защиты данных (см. статьи ASP.NET Core Защита данных и Поставщики услуг хранилищ ключей).

Примечание

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

Настройка поставщика TempData

Поставщик TempData на основе файлов cookie включен по умолчанию.

Чтобы включить поставщик TempData на основе сеанса, используйте метод расширения AddSessionStateTempDataProvider.

Порядок ПО промежуточного слоя важен. В предыдущем примере исключение возникает при вызове после . Дополнительные сведения см. в разделе .

Важно!

Если вы ориентируетесь на .NET Framework и используете поставщик TempData на основе сеансов, добавьте в проект пакет Microsoft.AspNetCore.Session.

Пример кода страницы, где сессия запущена

<? session_start(); ?>

<!DOCTYPE html><head><html lang=»ru»><meta charset=»UTF-8″><title>Пример скрипта Проверить запущена ли сессия php — сессия запущена</title>

<link rel=»stylesheet» type=»text/css» href=»https://dwweb.ru/__a-data/__all_for_scripts/__examples/__examples.css»>

</head>

   <body>

       <blockCenter>

           <h2>Пример скрипта Проверить запущена ли сессия php </h2>

           Здесь — сессия запущена

           <l>Результат</l>

           <div class=»kod»>

               <red><? if ($_SESSION) { echo ‘Сессия уже запущена ранее…’; } else { echo ‘Сессия не существует…’; } ?></red>

           </div>

       </blockCenter>

   </body>

</html>

Servlet1.java

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Servlet1 extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response){
try{
response.setContentType("text/html");
PrintWriter pwriter = response.getWriter();
String name = request.getParameter("userName");
String password = request.getParameter("userPassword");
pwriter.print("Welcome "+name);
pwriter.print("Here is your password: "+password);
HttpSession session=request.getSession();
session.setAttribute("usname",name);
session.setAttribute("uspass",password);
pwriter.print("<a href='Welcome'>view details</a>");
pwriter.close();
}catch(Exception exp){
System.out.println(exp);
}
}

Переходя к третьему примеру

Серверный механизм управления сессией (Session, SessionState)

Разберем, как работает механизм сессии со стороны сервера и со стороны клиента.

При стандартных настройках работы состояния сеанса для отслеживания серии запросов от одного клиента используется т.н. сессионная куки (session cookie). Алгоритм следующий:

Абсолютно для каждого нового запроса на сервер (неважно, разные это клиенты или один) ASP.NET генерирует уникальный идентификатор сессии. Идентификатор сессии представляет собой случайно сгенерированное число, закодированное с помощью специального алгоритма в строку длиной 24 символа

Строка состоит из литералов от A до Z в нижнем регистре, а также чисел от 0 до 5. Пример идентификатора — hjnyuijl1pam3vox2h5i41in

Если в течение текущего запроса данные клиента НЕ сохраняются для дальнейшей работы с ним, то и время жизни сессии этого клиента заканчивается (фактически не начавшись). При этом ранее сгенерированный идентификатор сессии становится недействительным (так как не был использован). В ответ на такой запрос клиент не получает ничего, чтобы связало его с новой сессией.
Если же данные клиента (например, имя, адрес доставки товара) сохраняются на сервере, ASP.NET связывает сохраненные данные с ранее сгенерированным идентификатором сессии. Далее создается специальная сессионная куки, и в нее записывается также этот идентификатор. Эта куки добавляется в ответ на запрос и сохраняется в браузере клиента. Таким образом, создается связь клиента и его персонализированной информации на сервере. Новая сессия для данного клиента создана.
При каждом следующем запросе клиент передает на сервер персональный идентификатор сессии через куки. Сервер сопоставляет идентификаторы и «узнает» клиента в рамках текущей сессии.
До тех пор пока клиент передает свой персональный ключ, сессия считается активной. Сессия может закончиться по разным причинам, например, вручную на стороне сервера или по истечении какого-то установленного времени (таймаут).

От теории перейдем к практике. Давайте запрограммируем данный алгоритм и посмотрим, как он выполняется. Для этого используем специальный класс HttpSessionState . При работе в контроллере можно воспользоваться свойством HttpContext.Session . Работать с сессией очень просто, как с любой NameValueCollection :

В этом участке кода мы записываем в состояние сеанса имя пользователя. Это имя мы забираем с html-формы, которую он нам отправил. Дополнительно через свойства мы узнаем, создана ли эта сессия только что, то есть в рамках текущего запроса (если да, то и значение свойства IsNewSession будет равняться true), и уникальный идентификатор сессии. Этот идентификатор после обработки запроса будет автоматически записан в сессионную куки (если еще нет) и отправлен в ответе клиенту.

В браузере клиента можно наблюдать соответствующую куки и идентификатор его сессии:

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

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

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

Item – возвращает элемент данных по его индексу Item – возвращает элемент данных по его ключу Remove(index) – удаляет элемент данных по его индексу Remove(key) – удаляет элемент данных по его ключу Clear() – удаляет все данные Count – возвращает общее количество элементов данных для текущей сессии Abandon() – принудительно завершить сессию SessionID — возвращает идентификатор текущей сессии IsNewSession – возвращает true если сессия была создана в рамках текущего запроса Timeout – возвращает число минут, допустимое между запросами, перед тем как сессия завершится по причине таймаута (по умолчанию, 20 минут)

Изменить настройки для сессии можно либо программно в коде посредством членов класса HttpSessionState , либо через конфигурацию приложения (файл web.config). Например:

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

Http Session Interface

Сервлеты в Java предоставляют интерфейс, известный как «HttpSessionInterface». Они состоят из различных методов, некоторые из которых обсуждаются ниже:

• public HttpSession getSession (логическое создание): этот метод получает сеанс, связанный с запросом. Если он недоступен или отсутствует, создается новый сеанс, основанный на указанном логическом аргументе.
• public String getId(): уникальный метод сеанса возвращается этим методом.
• public long getCreationTime(): время, когда был создан сеанс, возвращается этим методом. Измеряется в миллисекундах.
• public long getLastAccessedTime(): время, когда сеанс последний раз был доступен, возвращается этим методом. Измеряется в миллисекундах.
• public void invalidate(): сессия может быть признана недействительной с помощью этого метода.

Session Configurations Options

session.auto_start: автоматически начинает сессию.

По умолчанию выключена.

session.name: задаёт имя текущей сессии и сессионной куки

По умолчанию PHPSESSID.

Может быть изменено с помощью функции

session.save_path: путь по которому сохраняется информация о сессии

По умолчанию tmp директория сервера.

session.gc_maxlifetime: максимальное время жизни

По умолчанию 1440 секунд (24 минуты).

session.cookie_lifetime: время жизни куки, которая отправляется браузеру. По сути это значение, которое мы добавляем к time() когда
задаём

По умолчанию 0.

session.cookie_path: задаёт

По умолчанию ‘/’.

session.cookie_secure: задаёт

Если включить то куки будут отправляться только по HTTPS.

По умолчанию выключена.

session.use_strict_mode:
если включить то SID которые созданы не сервером будут отклонены.

По умолчанию выключена.

session.cookie_httponly: задаёт

Если включить куки будет доступна только по HTTP (и HTTPS). То есть

JavaScript

или
bbscript не смогут получить к куки доступ

По умолчанию выключена.

session.use_cookies: указывает нужно ли сохранять SID в

cookies

на стороне клиента.

По умолчанию включена.

session.use_only_cookies: заставляет сессию использовать
только

cookie

для хранения SID. Работает совместно с session.use_cookies

По умолчанию включена.

session.use_trans_sid: контролирует использование «прозрачных»
SID

Если включить — SID будет добавляться как параметр прямо в URL. Например:

Эту опцию обычно включают только тогда, когда нет поддержки

cookies

По умолчанию выключена.

Пользуйтесь trans sid с осторожностью так как это может поставить под угрозу безопасность пользователя.

• Пользователь может отправить URL содержащий активный SID другому человеку по email, irc и т.п.
• URL содержащая активный SID может быть сохранён на публично доступном компьютере.
• — Пользователь может заходить на ваш сайт с одним и тем же SID который он сохранил в закладках или
  истории браузера.

session.cache_limiter: указывает способ контроля за кэшем во время сессии.

Доступные варианты:

• nocache
• private
• private_no_expire
• public

По умолчанию
nocache.

Для сессий с

аутентификацией

нужно, чтобы кэширование в браузере было отключено.

session.cookie_samesite: контролирует доступности куки в кроссдоменных запросах.

Доступные варианты: Lax и Strict

Кросдоменные запросы могу быть не только от злоумышленников. Их может делать ваш сайт с разных поддоменов.
Либо вы можете следить за перемешением пользователя между своими проектами.