Как использовать сессии и переменные сессий в PHP

Что такое сессии в php?

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

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

С помощью сессии можно реализовать авторизацию пользователей, корзину интернет-магазина и другое.

Как уничтожить сессию

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

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

Функция session_destroy удаляет всё, что хранится в текущем сеансе. Таким образом, с последующими запросами вы увидите пустую переменную $_SESSION, поскольку данные сеанса, хранящиеся на диске, были удалены функцией session_destroy.

Как правило, функцию session_destroy нужно использовать, когда пользователь выходит из системы.

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

Попробую рассказать в паре абзацев.

Сессии – это механизм, который позволяет однозначно идентифицировать пользователя.
По-человечески это значит, что для каждого посетителя сайта можно создать уникальное “хранилище”, к которому будет доступ только у этого самого посетителя.
Хранилище это хранится в файле на сервере.

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

Что делать дальше?

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

The Logout script

Finally, Let’s create a logout.php file with the following code in it.

Step 1: creating a login form in html

Below is the Login Form in HTML. Paste it in a file named login.php

Step 1: creating registration form in html

We will create a PHP file named register.php with the following code in it. This is a simple HTML form with some basic validation. If you are not familiar with HTML then you can get it from many online sites who give ready-made html5 login form templates.

Автоматический запуск сеанса

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

В файле php.ini есть параметр session.auto_start, который позволяет запускать сеанс автоматически для каждого запроса. По умолчанию установлено значение 0 (выкл), и вы можете установить его на 1 (вкл), чтобы включить функцию автоматического запуска.

session.auto_start = 1

С другой стороны, если у вас нет доступа к файлу php.ini, и вы используете веб-сервер Apache, эту переменную можно задать с помощью файла .htaccess.

php_value session.auto_start 1

Если вы добавите строку выше в ваш .htaccess файл, то это должно автоматически запускать сессии в вашем PHP-приложении.

Всё хорошо?

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

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

Выбираем правильное хэширование

Идею хранения паролей нашли, то есть хранения не паролей, а их хэшей. А вот какой алгоритм хэширования выбрать?

Давайте посмотрим на то, что пробовали выше – простая функция md5. Алгоритма его расшифровки нет, но тем не менее md5 не рекомендуется для использования. Почему?

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

    select password from passwords where hash='e10adc3949ba59abbe56e057f20f883e';

Конечно, вы сами не будете использовать пароль 123456, но как насчет ваших пользователей? Да, 123456 можно подобрать и руками, но в таком случае никакие алгоритмы не помогут.
Наша же задача максимально позаботиться о юзерах, которые выбирают пароли сложнее qwerty. Думаем дальше, гуглим.

Помимо md5 есть множество алгоритмов хэширования, sha256, sha512 и еще целая толпа. Их сложность выше, но это не отменяет опять-таки существования таблиц с готовыми паролями.
Нужно что-то хитрее.

Делегирование полномочий

Давайте попробуем создать отдельный модуль. Назовём его совершенно бесхитростно — security.php, и оформим как отдельный скрипт. Будем подключать его ко всем закрытым страницам нашего проекта в самом начале. Внутри этого файла будем анализировать некие условия, а по итогам его работы выставлять специальный флаг в 0 или 1. Пусть этот флаг будет храниться в переменных сессии (массив $_SESSION в PHP).

Что нам это даёт? Мы можем запихать в этот скрипт сколь угодно хитрую логику, вплоть до анализа последних действий пользователя и добавления его в бан-лист по IP, либо блокировки его аккаунта на тот или иной срок. Но сперва реализуем очень базовую функциональность: будем сверять значение хэша, пришедшего из куки, с тем, что должно было бы получиться, если хэш не был искажён. Сервер знает IP, знает юзер-агент, знает пароль текущего пользователя… Кажется, всё готово!

Заглушка для авторизации

Функции, связанные с авторизацией, будут лежать в отдельном файле и своем пространстве имен. Создадим файл auth.php в api/v1/common – там, где уже лежит helpers.php.
Если вы разбирали уроки админки, особенно третий, про серверную часть, то эти пути вам будут знакомы. Если у вас свой проект, то кладите auth.php куда удобно.
Главное, потом правильно указать пути.

Содержимое auth.php

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

Метод, в котором сессия запускается функцией session_start, вы будете видеть часто.

Важно, чтобы функция session_start вызывалась в начале скрипта, перед отправкой чего-либо браузеру. В противном случае, вы столкнётесь с печально известной ошибкой Headers are already sent.

Как быть?

Очевидно, с этим надо что-то делать. Да, можно сразу бежать покупать сертификат и подключать SSL. Но можно сделать кое-что ещё до этого, и существенно снизить тем самым необходимость в нём. В конце концов, в том же ВКонтакте SSL стал принудительным всего полгода назад, а до этого как-то ведь жили.

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

Можно пойти дальше, и при создании хэша использовать юзер-агент. Теперь взломщику придётся использовать браузер той же версии, что и у нас (а в случае с IE ещё и с тем же набором плагинов тех же самых версий, что выходит уж очень маловероятно, особенно если взломщик не догадался подсмотреть юзер-агент).

Как запустить сессию

В этом разделе мы обсудим, как запустить сессию в PHP.

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

Как изменять и удалять переменные сеанса

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

Давайте посмотрим, как изменять переменные сессии.

Как обойтись без шифрования. хэширование

Фокус в том, что не нужно хранить пароли в открытом виде, но и не нужно шифровать их с возможностью расшифровки. Пароли нужно хэшировать и в базе хранить не пароль, а его хэш.
Хитрым образом закодированную строку, которую нельзя расшифровать. Например, не password, а 5f4dcc3b5aa765d61d8327deb882cf99

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

Например, есть простая функция хэширования md5. Вот так она работает

Как получить идентификатор сессии

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

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

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

Какие задачи решает сессия

Стандартные задачи, которые решают с помощью сессии, это

корзина интернет-магазина,
форма для заполнения пользователем, разбитая на несколько страниц сайта
(на первой мы спрашиваем имя, на второй email и т.д.),
авторизация пользователей на PHP.

Обработка входа с сессиями и файлами «куки» (cookie)

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

1. Пользователь открывает страницу входа на веб-сайт.
2. После отправки формы входа, сервер, на другом конце, аутентифицирует запрос, проверив введённые учётные данные.
3. Если учётные данные, введённые пользователем, верны, сервер создаёт новый сеанс. Сервер генерирует уникальное случайное число, которое называется идентификатором сеанса. Также, на сервере, создаётся новый файл, который используется для хранения информации, относящейся к сеансу.
4. Затем, идентификатор сеанса передаётся обратно пользователю, вместе с тем, что он запросил. За кулисами этот идентификатор сеанса отправляется в заголовке ответа «куки» PHPSESSID (так называется по умолчанию).
5. Когда браузер получает ответ от сервера, он получает заголовок куки-файла PHPSESSID. Если в браузере разрешены «куки», то он сохранит этот PHPSESSID, в котором хранится идентификатор сеанса, переданный сервером.
6. Для последующих запросов, «кука» PHPSESSID передаётся обратно на сервер. Когда сервер получает «куку» PHPSESSID, он пытается инициализировать сеанс с этим идентификатором сеанса.  Он делает это, загружая файл сеанса, который был создан ранее во время инициализации сеанса. Затем он инициализирует суперглобальную переменную массива $_SESSION с данными, хранящимися в файле сеанса.

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

Пишем в сессии

После инициализации мы можем записать что-нибудь в сессию.

Сделать это не сложно:

Предыстория

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

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

Проверяем работоспособность vue

Вроде бы, чего там может сломаться? Нам же практически не пришлось лезть в код vue, за исключением добавления кнопки Выйти в шапке админки.

Но попробуем пересобрать админку, чтобы убедиться, что все хорошо. Сначала в production режиме

    npm run build

Простая авторизация на php. | linuxblog.рф

В этой статье мы напишем очень простую авторизация на web странице. Мы не буде использовать базы данных и т.д. Все будет очень лаконично и просто.

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

<?php
session_start();
if($_SESSION['admin'] != "admin"){
header("Location: login.php");    
exit; 
}
?> 
Вы авторизованы !!!

session_start(); # Открыли сессию , обязательно условие при работе с сессиями.

header(«Location: login.php»);# производим редирект пользователя на страницу login.php

exit; # После функции header() обязательно завершаем выполнение скрипта при помощи функции exit(). Данный код очень просто, если у нас в массиве $_SESSION нету переменой admin равной значению ‘admin’ перенаправить на страницу авторизации.

Ну и за одно создадим страницу авторизации login.php :

<br /> 
<form method="post">
Username: <input type="text" name="user" /> <br /> 
Password: <input type="password" name="pass" /> <br />
<input type="submit" name="submit" value="Login" />
</form> 

Простой html код создания формы с двумя полями и кнопкой отправки, метод передачи данных post. Если мы все правильно сделали , то при попытки зайти на index.php нас должно выкидывать на форму авторизации.

Следующим этапом мы добавим обработчик данных из формы. Который будет принимать и сравнивать данные из формы. В этом примере у нас будет только один пользователь и хранить логинпароль мы будем прям в этом же файле. Пароль будет в зашифрованном виде c помощью функции md5(). А что бы узнать узнать хеш пароля попробуйте выполнить код echo md5(‘mypass’); 😉 Делать это мы будем по условию — только в том случае, если нажата кнопка формы.

У кнопки есть имя («submit»), а данные мы передаем методом post. Соответственно, мы можем просто проверить, существует ли элемент submit в массиве $_POST. Если есть — кнопка была нажата, и мы будем выполнять действия по проверке присланных данных, иначе — ничего делать не будем.

В файл формы (login.php) в самое начало добавим код :

<?php
session_start();
$users = 'admin';
$pass = 'a029d0df84eb5549c641e04a9ef389e5';
 if($_POST['submit']){
 if($users == $_POST['user'] AND $pass == md5($_POST['pass']))
{
 $_SESSION['admin'] = $users;
 header("Location: index.php");
 exit;
 }
else echo '<p>Логин или пароль неверны!</p>';
} 
?>  

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

В заключение мы сделаем ссылку для удаления всех данных сессии (закрыть сессию). Мы передаем один параметр — do и при этом присвоим ему значение «logout». А в блок PHP добавим проверку значения элемента do из массива $_GET. Если оно будет равно строке «logout» — мы просто удалим сессию с помощью session_destroy() . Откроем файл index.php и добавим код :

 <a href="index.php?do=logout">Logout</a> 

Вставим этот код сразу после  session_start(); для проверки полученных данных. 
if($_GET['do'] == 'logout'){
unset($_SESSION['admin']);
session_destroy();
} 

Сделаем счетчик на сессиях

Чтобы продемонстрировать работу с сессиями давайте реализуем
счетчик количества обновления страницы пользователем.

При каждом обновлении страницы он будет увеличиваться на единицу, а при закрытии браузера – обнуляться
(после закрытия нужно подождать 15-25 минут):

Создание переменных сеанса

В этом разделе мы изучим, как инициализировать переменные сессии в PHP.

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

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

Стандартная реализация

Итак, сессия в PHP по умолчанию хранится в файле. Её id сохраняется в cookie (если куки отключены — задействуется механизм передачи через адресную строку, если это не отключено в конфигурации). Время жизни такой сессионной куки по умолчанию — до момента закрытия браузера (и обычно его никто не меняет).

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

Если кто-то не понимает, чем это плохо — представьте себе, что у нас пользователь пользуется очень старым, либо очень плохо реализованным браузером. Мы ведь не можем гарантировать, что браузер надёжно шифрует куки? Да и вирусы всякие могут быть у пользователя на компьютере, и в случае особо серьёзной малвари может не спасти и шифровка — зловред может попытаться считать значения прямо из памяти, когда они расшифрованы.

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

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

Читаем из сессий

После того, как мы что-то записали в сессию, мы можем это оттуда извлечь:

Вместо заключения

Проблемы с dev режимом во vue – это неприятный момент. Мы хотим и апишечку подергать, и все удобства vue-cli использовать. И на елку влезть, и ничего не ободрать.
Возможно, есть более изящный способ обойти эти проблемы в dev режиме, но я их пока не нашел. Поэтому приходится подпирать код лишними условиями.