Php — login example

Образцы разделов авторизации

Ниже приведены несколько примеров разделов авторизации в документации API.

SendGrid

API ключ SendGrid

SendGrid предлагает подробное объяснение ключей API, начиная с основ, поясняя: «Что такое ключи API?». Контекстно раздел ключей API появляется вместе с другими разделами по управлению учетными записями.

авторизация Twitter

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

Amazon Web Services

авторизация Amazon

Amazon использует HMAC. Процесс достаточно сложный, чтобы включить полноценную диаграмму, показать шаги, которые должны выполнить пользователи.

Dropbox

Авторизация в Dropbox

Как и Twitter, Dropbox также использует OAuth 2.0. Их документация включает в себя не одну, а две диаграммы и подробное объяснение процесса.

login.php

Код:

Во первых тут стоит указать что вывод html и ошибок происходит в функции doIndex() которая вызывается в некоторых случаях, это не очень удобно поэтому кто хочет переписать — милости прошу, лично я сделал это для примера, к каждому проекту я пишу собственную авторизацию и стараюсь не повторяться. Поэтому здесь только пример.
А теперь по порядку.
1. подключаем конфиг
2. если уже авторизованы пересылаем на страницу members.php ( функция checkLoggedIn с параметром no )
3. Если отправлена форма, проверяем поля валидатором, если есть ошибки вызываем функцию doIndex(), если пароли не совпадают ставим ошибку, если есть ошибки вызываем функцию doIndex(), если все в порядке ставим сессию и отправляем на members.php, иначе опять вызываем функцию doIndex()
4. Функция doIndex() выводит html код, ошибки и форму для авторизации.

Виды режимов авторизации

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

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

Изображения

Слайд-шоуГалерея слайд-шоуМодальные изображенияЛайтбоксАдаптивная Сетка изображенияСетка изображенияГалерея вкладокОверлей изображенияСлайд с наложенным изображениемМасштабирование наложения изображенияНазвание наложения изображенияЗначок наложения изображенияЭффекты изображенияЧерно-белое изображениеТекст изображенияТекстовые блоки изображенийПрозрачный текст изображенияПолное изображение страницыФорма на картинкеГерой изображениеПараллельные изображенияОкругленные изображенияАватар изображенияАдаптивные образыЦентрировать изображенияМиниатюрыПознакомьтесь с командойЛипкое изображениеОтражение изображенияВстряхните изображениеПортфолио галереяПортфолио с фильтрациейМасштабирование изображенияИзображение увеличительное стеклоПолзунок сравнения изображений

3.4. Добавим кнопки «Войти» и «Выйти»

Как правило, авторизованный пользователь имеет больше возможностей по работе с системой, чем гость, иначе какой же смысл в авторизации?

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

Я являюсь ярым сторонником принципа DRY (don’t repeat yourself), поэтому напишем небольшой хелпер.

Эта кнопка будет отображаться, только если пользователь еще не вошел в систему.

Реализуем кнопку «Выйти из системы»

src/components/HelloWorldPage/HelloWorldPage.jsx

Настало время насладиться результатами нашего труда. Нажимаем на кнопку «Войти», используем свой github аккаунт для авторизации и… мы в системе! Кнопка «Войти» исчезла, зато появилась кнопка «Выйти». Проверим, что сессия сохраняется, для этого перезагрузим страницу. Кнопка «Выйти» не исчезла, а в redux-dev-tools можно найти информацию о пользователе. Отлично! Пока все работает. Переходим на страницу «Время», нажимаем на кнопку «Запросить» и видим, что timestamp отобразился — это сервер вернул нам данные.

На этом можно было бы закончить, но нам нужно «отшлифовать» наше приложение.

1. Ссылки на страницу «Время» должны отображаться только для авторизованных пользователей.
2. Если пользователь ввел адрес защищенной страницы в браузере, мы перенаправим его на страницу с авторизацией (в нашем случае — HelloWorldPage).
3. Если пользователь вышел из системы, мы должны удалить из глобального состояния его данные.

Последствия нехватки безопасности API

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

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

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

В целом, аутентификация и авторизация с помощью API служат следующим целям:

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

join.php

Итак исходник:

Если кратко описать работу скрипта получится что то вроде:
1. Если уже авторизованы пересылаем на members.php ( строка 4 )
2. Если существует $_POST ( если отправили данные с формы ) проверяем поля валидатором, проверяем наличие такого пользователя, если никаких ошибок нет, добавляем нового пользователя, ставим сессию и пускаем на members.php
3. Если есть ошибки — выводим
4. Выводим форму

Создание формы регистрации

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

   
   <?php
        mysql_connect ("localhost", "root","");//пишите свои настройки
        mysql_select_db("test") or die (mysql_error());//и свою бд
        mysql_query('SET character_set_database = utf8'); 
        mysql_query ("SET NAMES 'utf8'");
        error_reporting(E_ALL); 
        ini_set("display_errors", 1);
        if(isset($_POST)) {
        //проверяем, нет ли у нас пользователя с таким логином
        $query = mysql_query("SELECT COUNT(user_id) 
                FROM users WHERE 
                user_login='".mysql_real_escape_string($_POST)."'");
        if(mysql_result($query, 0) > 0)  {
                        $error = "Пользователь с таким логином уже есть";
           }
                        // Если нет, то добавляем нового пользователя
          if(!isset($error) )   {
                $login = mysql_real_escape_string(trim(htmlspecialchars($_POST)));
                // Убираем пробелы и хешируем пароль
                $password = md5(trim($_POST));
                mysql_query("INSERT INTO users 
                SET user_login='".$login."', user_password='".$password."'");
                echo 'Вы успешно зарегистрировались с логином - '.$login;
                exit();
        }  else   {
        // если есть такой логин, то говорим об этом
                 echo $error;
                }
        }
        //по умолчанию данные будут отправляться на этот же файл
        print <<< html
        <form method="POST">
                Логин <input name="login" type="text"><br>
                Пароль <input name="password" type="password"><br>
                <input name="submit" type="submit" value="Зарегистрироваться">
        </form>
   html;
   ?>

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

Примечание! Для тестирования я использую всего один файл, я его назвал mylogin.html (код файла ниже). Вы можете использовать в своих файлах и называть их как угодно, я здесь описываю сам процесс авторизации, поэтому применить его можно везде. Кстати, во всех файлах придется использовать функцию session_start(); для того чтобы Вы могли проверять авторизован пользователь или нет. И еще один момент, конечно же, пропишите свои настройки подключения к базе данных.

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

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

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

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

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

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

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

Cookies

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

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

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

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

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

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

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

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

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

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

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

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

Запомнить пользователя

Теперь нам надо запомнить что пользователь авторизован и точно знать кто это. Первое что приходит в голову — использовать для этого куки. Действительно — запихать в куки логин и id пользователя и всегда знать кто запрашивает страницу в данный момент.

Но это порочная практика. Почему? Потому что куки — это файл, который хранится у пользователя в браузере и данные из этого файла передаются серверу в каждом запросе. Во-первых, они передаются как текст, а это значит — их легко перехватить. Во-вторых, это простой текст, посылаемый пользователем. Поэтому его можно буквально переписать. Например, если мы решили хранить в куках логин пользователя «Вася» он может открыть управление куками в своем браузере, найти нужную куку и исправить ее на, скажем, «Admin». И все. Теперь при каждом запросе мы будем получать куку, которая нам будет сообщять юзернейм пользователя — «Admin».

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

То что я описал — это механизм сессии. В Perl, например, для использования сессий нужно загружать модули. А в php сессии поддерживаются из коробки. Фактически, все что вам нужно знать — это функция session_start() и массив $_SESSION. Это все. Сейчас расскажу.

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

Чтобы записать в сессию данные нужно просто записать их в массив $_SESSION. Сейчас нам надо помнить id юзера.

Все. Теперь каждый раз когда пользователь будет запрашивать скрипт, который использует сессии — вам будет доступно значение элемента $_SESSION.

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

Создаём регистрацию на PHP:

Для этого пишем скрипт который будет ниже:

PHP

HTML я не стал рассказывать, так как, там всё понятно, да и вообще программист должен разберется в коде.

3.2. Добавляем авторизацию

Устанавливаем redux-oauth

Примечание: мы используем redux-oauth для изоморфного сценария, но она также поддерживает и client-side only. Примеры конфигурации для различных случаев и демо можно найти на сайте библиотеки.

Примечание 2: redux-oauth использует cookie для авторизации, так как механизм local storage не подходит для изоморфного сценария.

Активируем плагин cookieParser для express

src/server.js

Настраиваем redux-oauth для серверной части приложения

src/server.js

Здесь происходит много интересного:

Мы должны вызвать функцию initialize из redux-oauth, которой передадим текущий URL, cookies и конфигурацию: адрес API и используемые OAuth-провайдеры.
Если в переданных cookie будет найден авторизационный token, то библиотека проверит его валидность у backend и в случае успеха сохранит информацию о пользователе в глобальном состоянии

Обратите внимание, что дальнейший код приложения выполнится только после того, как отработает initialize.
Перед тем, как отправить HTML клиенту, мы используем метод res.cookie. Этот метод сообщает express, что к HTTP-ответу необходимо добавить заголовок SetCookie, в котором нужно передать обновленный авторизационный токен

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

Согласно документации, нам также необходимо добавить редьюсер redux-oauth в корневой редьюсер.

Пользовательская страница авторизации

Итак, первое, что нам нужно, это создать шаблон пользовательской страницы входа. Для этого мы создаем страницу шаблона и называем ее, к примеру, page-login.php.

Затем, создаем новую страницу в панели администрирования и ставим постоянную ссылку для страницы авторизации.

WordPress автоматически подцепит шаблон page-login.php:

Форма входа

Поместите тег wp_login_form в код шаблона page-login.php для отображения формы авторизации:

<? php wp_login_form(); ?>

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

<?php  
$args = array(  
    'redirect' => home_url(),   
    'id_username' => 'user',  
    'id_password' => 'pass',  
   )   
;?>  
<?php wp_login_form( $args ); ?>

Здесь же вы можете, к примеру, добавить такие штуки как логотип и описание вашего сайта:

<div class="login-branding">  
    <a href="#" class="login-logo">Hongkiat.com</a>  
    <p class="login-desc">  
        Тестовое описание сайта.  
    </p>  
</div>  
<div class="login-form">  
<?php  
$args = array(  
    'redirect' => home_url(),   
    'id_username' => 'user',  
    'id_password' => 'pass',  
   )   
;?>  
<?php wp_login_form( $args ); ?>  
</div>

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

У нее темный фон с голубой кнопкой, которые соответствуют теме сайта Hongkiat.com:

Проверка связки имя-пароль

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

Но есть еще кое-что, на что мы обратим наше внимание

Во-первых, страница wp-login.php до сих пор остается доступной. Стоит поставить редирект с wp-login.php на созданную нами страницу, чтобы наши клиенты могли на неё попасть.

Для этого нужно добавить следующий код в файл functions.php используемой вами темы WordPress:

function redirect_login_page() {  
    $login_page  = home_url( '/login/' );  
    $page_viewed = basename($_SERVER);  
  
    if( $page_viewed == "wp-login.php" && $_SERVER == 'GET') {  
        wp_redirect($login_page);  
        exit;  
    }  
}  
add_action('init','redirect_login_page');

Не забудьте присвоить переменной $login_page значение адреса вашей страницы для входа.

Во-вторых, страница авторизации работает так как задумано только в случае, если попытка входа удалась. Но, что происходит, если вход не удался?

К примеру, введена неверная пара логин-пароль или оставлено пустое поле. Нас снова выбросит на wp-login.php.

Чтобы избежать этого добавляем следующую функцию в файл functions.php:

function login_failed() {  
    $login_page  = home_url( '/login/' );  
    wp_redirect( $login_page . '?login=failed' );  
    exit;  
}  
add_action( 'wp_login_failed', 'login_failed' );  
  
function verify_username_password( $user, $username, $password ) {  
    $login_page  = home_url( '/login/' );  
    if( $username == "" || $password == "" ) {  
        wp_redirect( $login_page . "?login=empty" );  
        exit;  
    }  
}  
add_filter( 'authenticate', 'verify_username_password', 1, 3);

Две эти функции выполняют несколько задач: переадресуют пользователей в случае неудачной попытки входа и дописывают к URL-адресу строки запроса login значение failed или empty:

wp-login.php

function logout_page() {  
    $login_page  = home_url( '/login/' );  
    wp_redirect( $login_page . "?login=false" );  
    exit;  
}  
add_action('wp_logout','logout_page');

Сообщение об ошибке

Мы будем показывать пользователю сообщение, и когда случается ошибка, и когда он выходит с сайта при помощи query string, значение которой мы поместили в URL. Для того чтобы получить значение из строки запроса, мы будем использовать переменную $_GET.

Поместите код, приведенный ниже, в шаблон страницы авторизации:

$login  = (isset($_GET) ) ? $_GET : 0;

Код, приведенный выше, проверяет, содержит ли переменная login что-либо и в противном случае приравнивает ее к значению 0.

Также мы будем отображать сообщения, основанные на значении переменной $error:

if ( $login === "failed" ) {  
    echo '<p class="login-msg"><strong>ERROR:</strong> Invalid username and/or password.</p>';  
} elseif ( $login === "empty" ) {  
    echo '<p class="login-msg"><strong>ERROR:</strong> Username and/or Password is empty.</p>';  
} elseif ( $login === "false" ) {  
    echo '<p class="login-msg"><strong>ERROR:</strong> You are logged out.</p>';  
}

И ниже, собственно, пример того, как может такое сообщение выглядеть:

Авторизация

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

authorization.php:

session_start();
$login=$_POST;
$pas=$_POST;
$db=mysqli_connect('localhost', 'root', '', 'mybase');
$query="SELECT * FROM users WHERE login='$login' AND BINARY pas='$pas'";
$result=mysqli_query($db, $query);
if (mysqli_num_rows($result))
$_SESSION=$login;
else
$_SESSION='er login';
header("Location: formreg.php");
mysqli_close($db);

В строке 7 формируется запрос на выборку строки с логином и паролем, полученными из формы. Перед полем
pas написано ключевое слово BINARY. Оно нужно
для того, чтобы при сравнении по
этому полю учитывался регистр символов. Если нужно, чтобы регистр учитывался и при сравнении логина, то
BINARY нужно написать перед ним. В примере делается запрос на выборку всех полей. На практике можно делать
выборку только тех полей, данные из которых нужно будет выводить на страницу.

После получения результата, проверяется, найдена ли указанная запись. Если запись есть, то логин записывается
в сессию. Если пользователь не найден, то вместо
логина пишется строка «er login». Можно написать другой текст,
но нужно быть уверенным, что он не совпадёт с каким-то логином. Затем происходит возврат на страницу
с формами.

На страницах сайта должен быть код, в котором происходит проверка — есть ли в сессии логин. И в зависимости
от этого определяется, как должна выглядеть страница. В нашем примере есть только одна страница. На ней и
сделаем проверку. Только код будет разделён на две части. Открытие сессии должно производиться до вывода
каких-либо данных, то есть, до HTML кода. Поэтому эта часть располагается в самом начале страницы. А остальной
код находится внутри тэга <body>, потому что он добавляет на страницу контнет.
Добавим в начало страницы такую строку:

<?php session_start(); ?>

Остальной скрипт расположим в теге <body>, в его начале:

<?php
$login=$_SESSION;
if ($login)
  {
  if ($login=='er login')
    {
    echo '<p>Введён неправильный логин или пароль</p>';
    $_SESSION='';
    }
  else 
  echo "<p>Здравствуйте, $login</p>";
  }
else 
echo '<p>Здравствуйте, гость</p>';
?>

Если в сессии есть логин, но в нём содержится строка «er login», то выводится сообщение, что логин или
пароль неправильный. После вывода сообщения логин становится пустым. Это сделано для того, чтобы сообщение
выводилось только один раз и при переходе на другие страницы не появлялось. Если логин другой, значит
пользователь авторизован и страница формируется как для зарегистрированных. Если логина нет, значит
авторизации ещё не было и страница выводится для не зарегистрированных пользователей.

Мы рассмотрели только общий принцип создания функции регистрации и авторизации. На реальных сайтах она
сложнее. Формы должны выводиться только для не авторизованных пользователей. Кроме того, нужно добавить
кнопку «Выход», которая отменяет авторизацию. При регистрации нужно делать
проверку формы, проверять уникальность логина и добавить
подтверждение пароля.