Php авторизация php auth user

Простая аутентификация на PHP

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

Disclaimer: статья рассчитана на совершенных новичков. Умудрённые опытом разработчики ничего нового здесь не найдут, но могут указать на возможные недочёты =).

Для написания системы аутентификации будем использовать базу данных MySQL/MariaDB, PHP, PDO, функции для работы с паролями, для построения интерфейса возьмём bootstrap.

Для начала создадим базу. Пусть она называется php-auth-demo. В новой базе создадим таблицу пользователей users :

CREATE TABLE `users` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `username` varchar(255) COLLATE utf8mb4_general_ci NOT NULL, `password` varchar(255) COLLATE utf8mb4_general_ci NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

Создадим конфиг с данными для подключения к базе.

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

 'php-auth-demo', 'db_host' => '127.0.0.1', 'db_user' => 'mysql', 'db_pass' => 'mysql', ];

И сделаем «загрузочный» файл, который будем подключать вначале всех остальных файлов.

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

В «загрузочном» файле мы будем инициализировать сессию и объявим некоторые функции-помощники.

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); > return $pdo; >

Функция pdo() даст нам доступ к объекту PDO в любом месте нашего кода.

Далее нам нужна форма регистрации. Разместим её прямо в файле index.php .

 

Здесь всё просто: два поля, кнопка и форма, отправляющая запрос на файл do_register.php методом POST. Процесс регистрации пользователя опишем в файле do_register.php .

prepare("SELECT * FROM `users` WHERE `username` = :username"); $stmt->execute(['username' => $_POST['username']]); if ($stmt->rowCount() > 0) < flash('Это имя пользователя уже занято.'); header('Location: /'); // Возврат на форму регистрации die; // Остановка выполнения скрипта >// Добавим пользователя в базу $stmt = pdo()->prepare("INSERT INTO `users` (`username`, `password`) VALUES (:username, :password)"); $stmt->execute([ 'username' => $_POST['username'], 'password' => password_hash($_POST['password'], PASSWORD_DEFAULT), ]); header('Location: login.php');

В самом начале подключим наш «загрузчик».

Потом проверим, не занято ли имя пользователя. Для этого сделаем выборку из таблицы указав в условии полученное из формы имя пользователя. Обратите внимание, для запросов здесь и далее мы будем использовать подготовленные запросы, что обезопасит нас от SQL-инъекций. Для этого в тексте SQL-запроса мы указываем специальные плейсхолдеры, а при выполнении ассоциируем с ними ненадёжные данные (ненадёжными данными следует считать всё, что приходит из вне – $_GET, $_POST, $_REQUEST, $_COOKIE). После выполнения запроса мы просто проверим количество возвращённых строк. Если их больше нуля, то имя пользователя уже занято. В этом случае мы выведем сообщение и вернём пользователя на форму регистрации.

Я написал «больше нуля», но по факту, из-за того, что поле username в таблице уникальное, rowCount() может нам вернуть лишь два возможных значения: 0 и 1 .

В приведённом выше коде мы использовали функцию flash() . Данная функция предназначена для «одноразовых» сообщений. Если вызвать её со строковым параметром, то она сохранит эту строку в сессии, а если вызвать без параметров, то выведет из сессии сохранённое сообщение и затем удалит его в сессии. Добавим эту функцию в файл boot.php .

function flash(?string $message = null) < if ($message) < $_SESSION['flash'] = $message; >else < if (!empty($_SESSION['flash'])) < ?>  unset($_SESSION['flash']); > >

А также вызовем её нa форме регистрации, для вывода возможных сообщений.

На данном этапе простейший функционал регистрации нового пользователя готов.

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

Login

Register

В виду простоты примера, она практически повторяет форму регистрации. Интереснее будет посмотреть на сам процесс логина в файле do_login.php .

prepare("SELECT * FROM `users` WHERE `username` = :username"); $stmt->execute(['username' => $_POST['username']]); if (!$stmt->rowCount()) < flash('Пользователь с такими данными не зарегистрирован'); header('Location: login.php'); die; >$user = $stmt->fetch(PDO::FETCH_ASSOC); // проверяем пароль if (password_verify($_POST['password'], $user['password'])) < // Проверяем, не нужно ли использовать более новый алгоритм // или другую алгоритмическую стоимость // Например, если вы поменяете опции хеширования if (password_needs_rehash($user['password'], PASSWORD_DEFAULT)) < $newHash = password_hash($_POST['password'], PASSWORD_DEFAULT); $stmt = pdo()->prepare('UPDATE `users` SET `password` = :password WHERE `username` = :username'); $stmt->execute([ 'username' => $_POST['username'], 'password' => $newHash, ]); > $_SESSION['user_id'] = $user['id']; header('Location: /'); die; > flash('Пароль неверен'); header('Location: login.php');

Здесь есть важный момент. Мы не запрашиваем пользователя из таблицы по паре username/password, а используем только username. Дело в том, что даже если вы захешируете пришедший из формы логина пароль и попробуете сравнить новый хеш с сохранённым в базе, вы ничего не получите. Password_hash() использует автоматически генерируемую соль для паролей и хеши будут всегда получаться разные. Вот результат функции password_hash , вызванной несколько раз для пароля «123»:

$2y$10$loqucup11.3DL1fgDWanoettFpFJuFFd0fY6BZyiP698ZqvA4tmuy $2y$10$.LF3OzmQRtJvuZZWeWF.2u80x3ls6OEAU5J9gLHDtcYrFzJkRRPvq $2y$10$iGj/nOCavShd2vbMZTC4GOMYCqDj2YSc8qWoeqjVbD1xaKU2CgAfi

Именно поэтому необходимо использовать функцию password_verify для проверки пароля. Кроме того, данная функция использует специальный алгоритм проверки и является безопасной для атак по времени.

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

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

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

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

prepare("SELECT * FROM `users` WHERE `id` = :id"); $stmt->execute(['id' => $_SESSION['user_id']]); $user = $stmt->fetch(PDO::FETCH_ASSOC); > ?> 

Welcome back, !

else < ?>

Registration

?>

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

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

Заключение

  • Используем PDO/MySQLi и подготовленные запросы для работы с базой данных.
  • В базе данных обязательно храним только хеш пароля.
  • Для хеширования пароля используем специальную функцию password_hash.
  • Для проверки пароля не делаем сравнение хешей, а используем специальную функцию password_verify.

Полный код примера доступен на гитхабе: ссылка на Github.

Источник

Аутентификация и авторизация на PHP

Изображение баннера

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

Тем не менее, желательно добавить немного функционала:

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

В Firefox это Library → History → Clear Recent History → Active Logins

В Chrome это Passwords and other sing-in data (в Clear browsing data → Advanced)

В Safari это Clear History

Если пароль поменялся, пользователя со старым паролем не выкинет и т.д.

Примечание о совместимости

Пожалуйста, будьте осторожны при кодировании строк заголовка HTTP.

Чтобы гарантировать максимальную совместимость со всеми клиентами, ключевое слово «Basic» должно быть написано с прописной буквой «B», строка realm должна быть заключена в двойные (а не одинарные) кавычки, и ровно один пробел должен предшествовать коду 401 в строке заголовка HTTP/1.0 401. Параметры аутентификации должны быть разделены запятыми, как показано в приведенном выше примере дайджеста.

Очистить глобальные переменные

Очистить значения переменных $_SERVER[‘PHP_AUTH_USER’] и $_SERVER[‘PHP_AUTH_PW’] можно с помощью функции unset()

HTTP Digest Authentication

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

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

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

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

Это более продвинутый вариант HTTP Аутентификации.

Можно использовать следующие опции ( полный список в RFC )

domain — домен

Необязательный список URI (через пробел), которые защищены данным запросом на аутентификацию.

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

base64 или HEX строка которую генерирует сервер. Клиент должен вернуть opaque неизменённым.

nonce — Уникальное HEX число или base64 число, которое сервер генерирует вместе с каждый 401 запросом.

nonce должен быть в одинарных кавычках (не в двойных)

nonce-count — HEX число, содержащее количество запросов, которые клиент отправил с nonce в запросе.

От английского stale — устаревший.

Флаг, который показывает на то, что предыдущий запрос от клиента был отклонён из за того, что значение nonce было несвежим.

Сервер должен ставить флаг stale в TRUE (регистронечувствительный) если пароль и имя пользователя верные и только nonce устарел.

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

Если сервер отказал в соединении а stale поставлен в FALSE, либо любое значение кроме TRUE, либо вообще отсутствует, значит клиент должен запросить логин и пароль снова.

qop — Quality of Protection

Опция для HTTP Digest Authentication. Может принимать значения «auth» или «auth-int». Влияет на то как создается хэш.

Если поставить в «auth» будет использоваться только запрошенный URI. Если в «auth-int» то также будет использовано тело запроса.

cnonce — Уникальный id сгенерированный клиентом. Это число помогает клиенту и серверу подтвердить, что у них есть известный общий секрет. Необходимо когда сервер отправляет qop. Не должно посылаться если сервер не использовал qop директиву.

Обзор Digest Аутентификации

  1. Клиент шлёт GET на сервер.

WWW-Authenticate: Digest realm=»AndreiR»,
qop=»auth,auth-int»,
nonce=»abcdefg…»,
opaque=»abcd…»,

    Пользователь вводит свои учётные данные

HA1 = MD5 хэш из имени пользователя, пароля и строки realm.

HA2 = MD5 хэш из метода аутентификации и запрошенного URI

Response = MD5 хэш из HA1, HA2, nonce, nonce-count, cnonce и qop

GET /
Authorization: Digest username=»andrei», realm=»AndreiR», uri=»/»
qop=auth, nc=00000001,response=»12345abc…»
nonce=»abcdefg…»,
opaque=»abcd…»,

  1. Сервер проверяет пришедшие данные. Если всё верно возвращает HTTP 200 OK, если неверно HTTP 403 Forbidden

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

HTTP Digest Аутентификация уязвима для атак посредника (MITM) так как сервер не может проверить идентичность клиента.

Невозможно использовать более сложные алгоритмы хэширования паролей, такие как bcrypt

Form Based Аутентификации

Про аутентификацию через HTML форму вы можете прочитать в статье «PHP Аутентификация через форму»

Источник

Читайте также:  Change password in php
Оцените статью