Содержание

Как правильно сделать авторизацию на php?

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

1

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

зайдет на эту страницу через день, то сессия сохранится?

Время жизни сессии настраивается в параметре gc_maxlifetime в файле php.ini, но, как правило, запоминание пользователя реализуется через cookie, которому можно указать произвольное время, в течение которого cookie будет действительным.

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

  • HTTP cookies,
  • работа с сессиями.

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

Сохранить эти данные вы можете на свое усмотрение, в cookies, в массиве сессий $_SESSION или в локальном хранилище, называемом localStorage.

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

Что именно использовать в качестве хранилища на клиенте, решать только вам, при необходимости устанавливать время протухания сессии, а еще и для разных роутов или уровней доступа, чаще всего используют куки, для их установки и отправки реализована специальная функция (https://www. php.net/manual/ru/function.setcookie.php) в языке.

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

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

By clicking “Отправить ответ”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Как сделать авторизацию на сайте php

В прошлом уроке мы изучили механизм взаимодействия с cookie в языке PHP.

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

Техническое задание

Начнём мы это дело с описания будущей системы. Пусть у нас будут следующие компоненты:

  1. Главная страница сайта с каким-либо содержимым. Вверху страницы выводится:
    • если пользователь авторизован: Добро пожаловать, %username%.
    • если пользователь неавторизован: Авторизация — слово является ссылкой, которая ведёт на форму авторизации.
      Авторизован пользователь или нет, определяется с помощью cookie.
  2. Страница с формой авторизации. Два инпута для логина и пароля и кнопкой «Вход». Если введены правильные логин и пароль, устанавливаются cookie со значениями переданных данных, а затем пользователя автоматически редиректит (перенаправляет) на главную страницу.
  3. Страница для разлогинивания — при переходе на неё cookie будут удаляться из браузера пользователя, а затем выполняется редирект на главную страницу.

Решение

Продумываем архитектуру

Первое, о чём нам нужно подумать — это то, как будут храниться элементы этой системы, и сколько их вообще будет.

Начнем с простого — для начала у нас должно получиться 3 странички, которые мы описали в ТЗ.

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

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

Пишем код

Все исходники по данному заданию доступны здесь.

База данных

Ну вот, всё продумали, осталось только написать. Предлагаю начать с нашей базы данных. Создадим файл usersDB.php и запишем в него несколько пользователей.

Функции проверки авторизации

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

В цикле мы пробегаемся по базе данных пользователей и пытаемся найти пользователя с переданными логином и паролем. Если такой пользователь в массиве найден — возвращаем true. Иначе — false.

Давайте теперь ещё напишем функцию, которая будет возвращать логин текущего пользователя. Эта функция будет проверять текущие значения cookie с ключами login и password с помощью уже существующей функции checkAuth. При этом если пользователь найдётся, то она вернёт его login, а иначе — null. Назовём эту нашу новую функцию getUserLogin.

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

Главная страница

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

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

Форма авторизации

Давайте теперь сделаем форму авторизации — создаём файл login.php и для начала набрасываем саму HTML-форму. Шаблон получился следующим.

Давайте теперь добавим логику проверки переданных данных.

Логика простейшая — если был отправлен POST-запрос, проверяем правильные ли логин и пароль были переданы.

Если нет — то создаём переменную $error, в которой пишем об ошибке авторизации. Позже в шаблоне выводим эту ошибку, если эта переменная объявлена.

Если же авторизация прошла успешно, мы устанавливаем cookie с ключами login и password, в которые помещаем значения из POST-запроса. После этого выполняем редирект на главную страницу.

Редирект делается с помощью заголовка в HTTP-ответе. Этот заголовок называется Location и выглядит следующим образом:

Для формирования заголовков в PHP используется функция header – ознакомиться с ней более детально вы можете здесь.

Теперь можно попробовать нашу страничку в действии. Давайте для начала введём несуществующую пару логина и пароля. Например, 123:123.

Мы увидим соответствующую ошибку.

Теперь давайте зайдем под пользователем user. В нашей БД для него указан пароль 123. Пробуем.

Успех! Нас автоматически перекинуло на главную страницу, где мы видим приветствие для данного пользователя!

Безопасная система авторизации

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

Хеширование паролей

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

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

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

Для чего это делается? Да просто потому, что если сайт будет каким-то образом взломан, то злоумышленник в базе данных не найдёт паролей в открытом виде — только хеши. А так как из хеша получить пароль довольно сложно (при условии, что хеш-функция надежна и используется надёжный пароль), то пароль он не узнает. Следовательно:

  1. злоумышленник не сможет использовать пароль для входа на взломанный сайт;
  2. он также не сможет использовать этот пароль для входа под тем же логином и паролем в другие места (ведь довольно часто люди используют одинаковые пароли для всего).

Вычисляются хеши с помощью хеш-функции. Хеш-функции при этом вычисляют хеши следуя алгоритмам хеширования. Сейчас в PHP для хеширования следует использовать функцию password_hash(), а для проверки хеша — password_verify(). Если вы в каком-то уроке увидите, что для хеширования паролей используется md5 — бегите оттуда, такие хеши вскрываются за несколько минут, она устарела ещё лет 10 назад.

Авторизационные токены

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

И потом пользователь с помощью cookie передает этот токен на сервер, где он сравнивается со значением в базе данных. Если они равны, то считаем пользователя авторизованным. Для чего? Дело в том, что куки могут быть похищены злоумышленниками (очень многими способами, не будем об этом в этой статье, кому интересно — погуглите). И если злоумышленнику попадет в руки токен — он не сможет получить исходный пароль. О том, почему это так важно, я уже объяснил.

Заключение

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

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

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

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

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

С местом хранения определились. Теперь перейдём непосредственно к алгоритму авторизации:

  1. Создать форму регистрации на HTML.
  2. Получить данные из формы в скрипте-обработчике.
  3. Проверить полученные данные, и если они некорректны, то сделать редирект обратно на форму регистрации.
  4. Если данные корректны, то записать их в базу данных.

Вот и весь процесс регистрации пользователя на сайте. То есть регистрация — это сохранение информации о пользователе на сайте.

Дальнейшим пунктом является авторизация пользователя на сайте, однако, прежде чем к нему переходить, расскажу об одном важном моменте в форме регистрации — пароле. Я Вам настоятельно рекомендую не хранить пароли в открытом виде (например так, «123456«). Обязательно их шифруйте, хотя бы с помощью функции md5(). И в базе данных храните именно зашифрованный пароль.

Теперь авторизация. Первое, что Вы должны понять — это то, что информация об авторизации должна где-то храниться. Самый простой вариант — это хранение информации в сессии (или в cookie). А теперь алгоритм:

  1. Создать форму авторизации пользователя на HTML, куда пользователь должен будет ввести свой логин и пароль.
  2. В скрипте-обработчике принять данные от пользователя. Если Вы меня послушались, и храните шифрованные пароли в базе данных, то сначала шифруйте полученный пароль. Если же в базе данных лежат открытые пароли, то шифровать не надо.
  3. Проверить правильность введённых данных, и если логин и пароль совпадают с существующим пользователем в базе данных, то записываете в cookie или сессию информацию с логином и шифрованным паролем (либо открытым паролем, если Вы его не шифровали).
  4. Если логин и/или пароль введены неверно, то делать редирект обратно на форму авторизации.

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

И последнее. Как делается кнопка «Выход«? Очень просто. При нажатии на эту кнопку, стираются cookie, либо сессия. Таким образом, пользователь автоматически вылетает с сайта.

Как видите, всё элементарно, но при реализации этого алгоритма у Вас обязательно возникнет множество вопросов. Например, что делать при регистрации пользователя, логин которого уже имеется в базе данных. Реализация различных проверок входных данных, реализация проверки существования e-mail и прочее — всё это является достаточно сложным, если Вы делаете это в первый раз. Однако, самый сок я выдал. Если будут вопросы при реализации, то спрашивайте либо на форуме, либо в комментариях.

В данной статье я привёл лишь алгоритм, а чтобы научиться его реализовывать нужно знать PHP и MySQL, которые максимально подробно разобраны в этом обучающем курсе: http://srs.myrusakov.ru/php

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk. com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

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

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

Комментарии ( 114 ):

Респект и Уважуха тебе Михаил! Хочу задать два вопроса: — долго ли Ты обучался всему этому; — как сделать авторизацию пользователей как В Контакте (всмысле каждому пользователю разные страницы)? Твой постоянный читатель с Украины!

Обучаться созданию авторизации не нужно. Нужно обучаться PHP и MySQL. Для этого мне потребовалось 2-3 месяца, а после пошло уже совершенствование, которое происходит и сейчас.

А в денвере (Denwer) нельзя создавать скрипты или страницы так, чтобы в одном окне код, а в другом результат? Общем как в html-редакторе.

Нет, поскольку Denwer — это не редактор, а пакет сервера apache, интерпретатора php, mysql, phpmyadmin и так далее, но никак не html-редактор.

Видел в нете редакторы php. Это то же самое что и html-редактор? Или они не будут показывать виполнение скриптов?

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

Здравствуйте, Михаил! А возможно ли сделать регистрацию на сайте без PHP, то есть просто ссылка на какой нибудь сторонний ресурс, где можно хранить базу подписчиков??)

Да, можно. Только тогда будет не регистрация, а просто авторизация через сторонний сервис. Например, такое позволяют Яндекс, Контакт и многие другие популярные сервисы.

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

В этой статье вы узнаете, как сделать PHP-авторизацию (authentication) на сайте с помощью данных, полученных от пользователя при регистрации. Будем использовать таблицу MySQL, а сама PHP-авторизация будет работать с применением сессий и cookie. Материал не следует рассматривать, как пошаговое руководство. Зато он помогает понять, как работает PHP-авторизация в целом.

В первую очередь нужно сверстать главную страницу веб-сайта, поместив её в корне в папку template. Для этого создаём файл index.html с формой ввода логина и пароля, кнопкой «Вход», вот её код:

Мы используем метод передачи post, который необходим. Нам ведь не нужно, чтобы в процессе PHP-авторизации пароль и логин «светились» в адресной строке.

Когда форма готова, создаём главный контроллер — наиболее важный файл сайта, лежащий в корне — index.php. Как раз он и будет запускаться во время входа. Код выглядит следующим образом:

Теперь разберёмся подробнее, как всё работает.

В первых 3 строках просто подключаются файлы с функциями, необходимыми для дальнейшего использования в коде. О них поговорим потом. Далее проверяем, был ли передан get-параметр action=out . В случае его передачи пользователь нажал на ссылку выхода с веб-сайта. Код ссылки, который нужно добавить в файл, содержащий код формы для входа:

Потом у нас идёт условие, которое проверяет, авторизован ли ты (if (login())). То есть функция возвращает нам true, если юзер вошёл на сайт. В противном случае возвращается false. Когда вернулось true, в переменную $UID записывается id юзера. Что касается переменной $admin, то в неё пишется результат работы функции is_admin($UID) . Она определяет, является ли наш юзер админом, возвращая true, если это так и false в обратном случае. Потом эти 2 переменные понадобятся, чтобы вывести определённые элементы на странице.

Итак, форму PHP-авторизации можно вывести следующим условием:

Аналогичная ситуация и с переменной $admin. Последний код тоже можно поместить в файл с формой.

Если функция login() вернёт false (юзер не вошёл на сайт), мы проверим, а нажал ли он вообще на кнопку входа на сайт, которая включена в нашу форму PHP-авторизации:

Если это так, запускается функция enter() , авторизующая пользователя. Если ошибки отсутствуют, а пользователь вошёл успешно, создаём те же две переменные: $UID и $admin. В обратном случае переменные не создаются никакие, ведь пользователь является гостем.

Давайте посмотрим на алгоритм работы:

А теперь рассмотрим все функции, вызываемые в коде. Вот функция входа на сайт:

Сначала функция проверит, а заполнено ли поле для ввода пароля и логина для PHP-аутентификации. Если да, работа программы продолжается, в противном случае в массив $error пишется текст ошибки, и происходит возвращение в основную программу, которая после того, как узнает размерность полученного массива, пользователя не авторизует.

Но если работа функции enter() будет продолжена, мы проверим, а существует ли в базе данных запись с таким ником. Когда записи нет, возвращается массив с ошибкой. Когда есть, введённый пароль сравнивается со значением, которое хранится в БД.

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

Когда хэши совпадают, происходит авторизация с помощью скрипта. При отсутствии совпадений, возвращается ошибка.

Давайте подробно остановимся на том, что значит «авторизироваться». В нашем скрипте информация о PHP-авторизации хранится в cookie и сессии. В сессию записывается id пользователя:

Кроме того, создаются 2 cookie: login и password. Продолжительность жизни — 50 тыс. секунд. В первый пишется логин, во 2-й — хэш пароля.

В данной строке выполняется функция, которая устанавливает время последней активности юзера. Код:

С помощью функции перезаписываются поля online и last_act в базе данных. Здесь, кстати, важно убедиться, что эти поля существуют (оба имеют тип int).

Теперь посмотрим на алгоритм работы функции enter() :

Идём дальше. Следующая функция нужна для проверки, авторизирован ли юзер на сайте — login() .

Возникает вопрос, почему для авторизации используем и сессию, и cookie? Всё дело в том, что при закрытии браузера сессия «умирает», а пользователь автоматически разлогинивается. А вот cookie хранятся определённое время, задаваемое нами (50 тыс. секунд).

Дальше у нас функция online() . Её нужно запускать первой на всех модулях и страницах будущего сайта. В первую очередь, она проверяет, прошёл ли пользователь PHP-авторизацию/аутентификацию, что важно для дальнейшей работы скрипта. Во вторую очередь, она выполняет обновление времени последней активности, а также помогает в перспективе выводить систему онлайн-пользователей.

Наша функция вернёт true, когда юзер авторизирован, а в обратном случае — false. При этом в процессе работы обновится время жизни cookie или они будут созданы, если вообще не существуют.

Очередной алгоритм работы:

Когда есть сессия и cookie, обновляется время жизни cookie. Чтобы это реализовать, они удаляются, время смерти устанавливается на одну секунду раньше текущего времени, потом устанавливаете заново. Также нужно учесть, что функция lastAct() обновляет время последней активности. Возвращается, разумеется, true.

Когда сессия есть, а cookie почему то нет, то по id юзера мы получаем из базы данных логин и хэш пароля, потом пишем их в cookie. Возвращается true.

Когда сессии нет, проверяем, существуют ли cookie. Традиционный пример — PHP-авторизация после перезапуска браузера, когда сессия слетела, но cookie всё ещё живы. Становится сложнее, ведь нужно проверить, а совпадает ли пара пароль-логин с какой-нибудь строкой из базы данных. Ведь пользователь легко мог сменить cookie в настройках для сайта. Если пара нашлась, создаётся переменная сессии, возвращается true. Если пара не нашлась, возвращается false.

Если у нас самый печальный вариант — ни сессии, ни cookie не оказалось, возвращается false.

Сейчас глянем на функцию is_admin($UID) , определяющую является ли user админом. Если вам это не надо, опустите данную функцию и её вызовы в контроллере. Но учтите, что для вывода контента на страницу для админов она бывает полезна. К тому же, она проста и основана на одном столбце в базе данных в таблице users (столбец prava, тип int).

Когда наш юзер обыкновенный пользователь, значению в столбце присваивается 0, иначе — 1. Соответственно, в первом случае вернётся false, во втором — true.

Последняя функция — это out() . Она проста и удаляет все «следы» юзера — и сессию, и cookie.

Код всех наших функций нужно поместить в файл lib/module_global.php, подключаемый в начале работы контроллера.

Итак, мы написали функциональную, но простую PHP-регистрацию/аутентификацию/авторизацию для сайта. Также заложили фундамент для дальнейших возможностей по администрированию и не только. Такая PHP-авторизация не слетит после перезапуска браузера, т. к. мы используем cookie. Предусмотрен и выход с сайта.

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

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

Настройка базы данных:

Для начала нам надо создать и настроить базу данных, для этого заходим в PhpMyAdmin.

Создание базы данных:

Создаём базу данных, называем её user-login и выбираем кодировку utf8_general_ci.

Нажимаем кнопку, создать БД

Создание и настройка таблицы в БД:

Называем таблицу users, и настраиваем её, я не буду объяснять что каждая настройка значит, так как эта статья не о том как работать с БД, а просто покажу на скриншоте, после нажимаем сохранить.

База данных у нас готова, теперь надо подключится к ней.

Подключение БД к PHP:

Для этого создаём файлы connect.php, index.php и checkin.php. Сначала мы в connect.php подключаемся к самой БД, для этого пишем код ниже.

Подключаем connect.php к index.php

Проверяем скрипт, для этого запускаем программу.

После того как проверили на работа способность, можете убрать вывод надписи «подключение к базе данных прошло успешно».

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

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

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

Создаём авторизацию на PHP:

Код будет очень сильно похож на файл регистрацию, но есть ряд не больших отличий.

Информацию о функции password_verify найдёте здесь, как видите код очень простой, но это ещё не всё, дальше вы сами напишите.

Что ещё надо сделать:

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

Вывод:

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

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

Разрешить приложениям PHP принимать решения по управлению доступом на уровне приложений

  • Статья

от Тали Смит

Введение

Вы можете предоставить ключевую информацию об управлении доступом в приложение PHP, чтобы облегчить управление доступом на уровне приложения, если это необходимо. Расширяемость Microsoft® .NET в Internet Information Services 7 (IIS 7) и более поздних версиях позволяет очень легко добавлять настраиваемые функции проверки подлинности или авторизации или дополнять существующие функции контроля доступа пользовательскими функциями.

Например, вы можете:

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

PHP может интегрироваться с моделью безопасности IIS путем выполнения сценариев PHP при олицетворении аутентифицированного пользователя, предоставленного IIS, но аутентифицированный пользователь должен быть пользователем Windows®, а списки управления доступом (ACL) для содержимого приложения PHP должны предоставлять доступ каждому олицетворяемому пользователю. Списки управления доступом должны управляться на протяжении всего жизненного цикла приложения и, во многих случаях, при перемещении приложения между серверами.

Благодаря IIS и FastCGI PHP может использовать модель выполнения, упрощающую управление безопасностью. Сценарии PHP могут выполняться с использованием идентификатора пула приложений, к которому принадлежит приложение. Эта модель имеет следующие преимущества:

  • Контент может предоставлять доступ для одного удостоверения, удостоверения пула приложений. В качестве альтернативы, если вам не нужна изоляция пула приложений, вы можете предоставить доступ группе IIS_IUSRS, которая позволяет всем пулам приложений IIS на любом компьютере IIS иметь доступ. Это значительно упрощает развертывание и текущее управление приложением.
  • Вся безопасность доступа может управляться на уровне приложений с помощью функций авторизации приложений; его можно применять единообразно к частям приложения, которые не соответствуют физическим ресурсам и поэтому не могут иметь разрешений на основе ACL.
  • Нет необходимости выполнять олицетворение, что может повысить производительность.

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

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

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

Настройка базовой проверки подлинности

  1. Запуск Диспетчер IIS (Inetmgr.exe).

  2. Разверните узел сервера, а затем разверните узел Sites .

  3. В дереве слева щелкните веб-сайт, на котором размещено приложение, которое вы хотите защитить.

  4. В группе функций IIS дважды щелкните Аутентификация . Здесь вы можете увидеть доступные методы аутентификации, соответствующие установленным модулям аутентификации. По умолчанию анонимная аутентификация включена

  5. Щелкните правой кнопкой мыши Анонимная аутентификация и выберите Отключить .

  6. Щелкните правой кнопкой мыши Basic Authentication и выберите Enable .

    Рисунок 1: Страница аутентификации

  7. В дереве слева щелкните тот же веб-сайт, который вы выбрали на шаге 3.

  8. На панели Действия щелкните Перезагрузить .

  9. Закрыть диспетчер IIS. Обратите внимание, что в функции аутентификации видны только встроенные схемы аутентификации.

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

Настройка проверки подлинности с помощью форм

Обычная проверка подлинности может быть небезопасным способом обеспечения проверки подлинности через Интернет, поскольку браузер отправляет пароль в виде открытого текста. Чтобы предотвратить раскрытие пароля, вы должны использовать только базовую аутентификацию через соединения Secure Sockets Layer (SSL). Обычная проверка подлинности требует, чтобы пользователь вошел в систему с локальной учетной записью Windows или учетной записью домена, хранящейся в Windows Active Directory®. Из-за этого пользователи, прошедшие проверку подлинности с помощью базовой проверки подлинности, при желании могут быть олицетворены.

Проверка подлинности с помощью форм — это функция проверки подлинности Microsoft® ASP.NET, которую можно использовать для содержимого любого приложения в IIS, используя преимущества механизма интегрированного режима ASP. NET. Перед использованием проверки подлинности с помощью форм убедитесь, что на сервере установлена ​​ASP.NET, а приложение PHP использует пул приложений, настроенный для работы в интегрированном режиме (по умолчанию). Для многих веб-сайтов проверка подлинности с помощью форм ASP.NET может быть лучшим вариантом по следующим причинам:

  • Она позволяет приложению предоставлять возможность входа в систему как неотъемлемую часть приложения.
  • Поддерживает произвольные хранилища учетных данных, включая встроенную поддержку баз данных Microsoft® SQL Server® и учетных записей Windows. Доступны многочисленные поставщики хранилища учетных данных с открытым исходным кодом, или приложение может предоставить пользовательские.
  • Предоставляет расширенные функциональные возможности для безопасного управления билетами аутентификации.

Чтобы настроить проверку подлинности с помощью форм:

  1. Запустите Диспетчер IIS (Inetmgr. exe).

  2. Разверните узел сервера, а затем разверните узел Sites .

  3. В дереве слева щелкните веб-сайт, на котором размещено приложение, которое вы хотите защитить.

  4. В группе функций IIS дважды щелкните Аутентификация .

  5. Щелкните правой кнопкой мыши Проверка подлинности с помощью форм и выберите Включить .

  6. Щелкните правой кнопкой мыши Анонимная аутентификация , а затем нажмите Включить .

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

    Рис. 2. Аутентификация с помощью форм и анонимная аутентификация включены

  8. В дереве слева щелкните веб-сайт, на котором размещено приложение, которое вы хотите защитить.

  9. Под Группа функций IIS , дважды щелкните Модули .

  10. Дважды щелкните модуль FormsAuthentication и снимите флажок Вызывать только для запросов к приложениям ASP.NET или управляемым обработчикам .

    Рисунок 3. Включение проверки подлинности с помощью форм для всех запросов

  11. Щелкните OK . Это позволяет модулю проверки подлинности с помощью форм предоставлять службы проверки подлинности для всех запросов, независимо от запрашиваемого содержимого приложения. Это позволяет вашему PHP-приложению использовать аутентификацию с помощью форм.

Вы можете изменить ряд параметров конфигурации, управляющих поведением модуля проверки подлинности с помощью форм (см. документацию по адресу https://msdn.microsoft.com/library/1d3t3c61.aspx):

  • URL-адрес страницы входа по умолчанию.
  • Тайм-аут и период автоматического продления билета проверки подлинности.
  • Следует ли использовать билеты проверки подлинности без файлов cookie (на основе URL) или на основе файлов cookie, или поддержку автоматического определения файлов cookie.
  • Требуется ли для проверки подлинности с помощью форм SSL (рекомендуется).
  • Уровни шифрования билета проверки подлинности.

Вы также можете настроить хранилище учетных данных для использования с проверкой подлинности с помощью форм, выбрав соответствующего поставщика членства. По умолчанию вы можете использовать либо поставщика членства на основе SQL Server (по умолчанию настроенного на использование локального экземпляра SQL Server Express), либо поставщика членства Active Directory (по умолчанию настроенного на использование локального хранилища учетных записей Windows). Однако вы также можете загрузить и использовать сторонних поставщиков членства или разработать собственного поставщика членства для работы с существующим хранилищем учетных данных вашего приложения.

Настройка авторизации

Авторизация по URL-адресу IIS — это новый механизм авторизации, который позволяет приложению создавать декларативные правила авторизации внутри самого приложения. Эти правила могут предоставлять или запрещать доступ к частям приложения в зависимости от пользователя, прошедшего проверку подлинности, и участия пользователя в ролях. Функция авторизации URL-адресов IIS — это функция, отдельная от функции авторизации URL-адресов ASP.NET. Он похож по функциональности, но поддерживает немного другой синтаксис конфигурации и доступен, даже если ASP.NET не установлен. Любая функция может использоваться для обеспечения авторизации пользователей и ролей на основе конфигурации для приложений PHP.

Настроить авторизацию URL-адреса

  1. Запустить Диспетчер IIS (Inetmgr.exe).

  2. Разверните узел сервера, а затем разверните узел Sites .

  3. В дереве слева щелкните мышью на веб-сайте, на котором размещено приложение, которое вы хотите защитить.

  4. Дважды щелкните Правила авторизации .

  5. Щелкните Добавить запрещающее правило и выберите Все анонимные пользователи .

    Рисунок 4. Добавление правила авторизации для запрета анонимных пользователей

  6. Щелкните OK .

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

  8. На панели Действия щелкните Перезапустить .

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

Настройка авторизации на основе ролей

Авторизация по URL позволяет создавать правила разрешения или запрета, которые применяются к:

  • Анонимным пользователям.
  • Конкретный пользователь.
  • Пользователь в одной или нескольких ролях.

Правила на основе ролей могут быть отличным способом управления разрешениями для большой группы пользователей.

При использовании ролей информация о членстве в ролях предоставляется модулем «Роли». Модуль «Роли» использует модель поставщика для получения ролей для конкретного пользователя, аналогичную модели поставщика членства.

  1. Запустить Диспетчер IIS (Inetmgr.exe).

  2. Разверните узел сервера, а затем разверните узел Sites .

  3. В дереве слева выберите веб-сайт, на котором размещено приложение, которое вы хотите защитить.

  4. В разделе ASP.NET дважды щелкните Роли .NET .

  5. На панели Действия щелкните Включить .

    Рисунок 5. Включение ролей .NET

  6. На панели Действия щелкните Добавить .

  7. В поле Name введите Admin

    Рисунок 6. Добавление роли .NET

  8. Щелкните OK .

  9. В дереве слева выберите веб-сайт, на котором размещено приложение, которое вы хотите защитить.

  10. В разделе ASP.NET дважды щелкните Пользователи .NET .

  11. На панели Действия щелкните Добавить .

  12. Введите учетные данные пользователя и нажмите Далее .

  13. Установите флажок Роль администратора , чтобы добавить нового пользователя к этой роли.

  14. Нажмите Готово .

  15. В древовидном представлении слева щелкните Интернет щелкните веб-сайт, на котором размещено приложение, которое вы хотите защитить, используемое в шаге 9.

  16. В группе функций IIS дважды щелкните Модули .

  17. Дважды щелкните модуль RoleManager , снимите флажок Вызывать только для запросов к приложениям ASP.NET или управляемым обработчикам , а затем щелкните OK .

  18. Дважды щелкните модуль DefaultAuthentication , снимите флажок Invoke только для запросов к приложениям ASP.NET или управляемым обработчикам и нажмите OK .

  19. В представлении в виде дерева слева щелкните подкаталог Admin под щелчком веб-сайта, на котором размещено приложение, которое вы хотите защитить, используемое в шагах 9 и 15.

  20. Дважды щелкните Правила авторизации .

  21. Удалите все существующие правила, щелкнув каждое правило, а затем нажав Удалить .

  22. В окне Подтвердить Удалить нажмите Да .

  23. Щелкните Добавить разрешающее правило , а затем выберите Указанные роли или группы пользователей .

  24. Введите admin в соответствующее текстовое поле и нажмите OK .

    Рисунок 7. Добавление разрешающего правила для роли администратора

  25. Закрыть диспетчер IIS.

Интеграция PHP с IIS 7.0 и более поздних версий

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

Вы можете использовать следующие переменные сервера для проверки аутентифицированного пользователя и/или принятия решений об аутентифицированной личности:

  • LOGON_USER – имя аутентифицированного пользователя. Пусто, если аутентифицированный пользователь является анонимным.
  • AUTH_TYPE — схема аутентификации, которая использовалась для аутентификации пользователя.
  • Комплект для обучения PHP в Windows

Предоставление профилям пользователей IBM i разрешений на доступ к PHP при использовании базовой аутентификации — техническая поддержка Rogue Wave

Выпуск

IBM HTTP Server обеспечивает базовую аутентификацию Apache с использованием профилей пользователей IBM i. Когда базовая аутентификация используется таким образом, дочернее задание FastCGI, работающее под Apache, предполагает профиль пользователя запрашивающей стороны, заменяя профиль QTMHHTTP по умолчанию на время выполнения запроса. Это может привести к фатальной ошибке для любого запроса Apache, если у пользователя нет прав для записи в журналы Apache. Это также может привести к фатальной ошибке для запросов PHP, если у пользователя нет прав доступа к сокету FastCGI. В этой статье рассказывается, как назначить разрешения пользователю *PUBLIC, чтобы предотвратить эти ошибки.

Среда

Сервер Zend для IBM i версии 6 или выше, работающий на любой поддерживаемой версии IBM i, использующий профили пользователей IBM i для базовой аутентификации.

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

IBM i Apache HTTP — аутентификация сервера с использованием профилей пользователей IBM i

Разрешение

Убедитесь, что *PUBLIC может записывать файлы журнала Apache.   Из командной строки 5250 при входе в систему с профилем пользователя класса *SECOFR:

Версии Zend Server 2020. x, Zend Server 2021.x и выше
Версии Zend Server 9.1.x, Zend Server 2018.x, Zend Server 2019.x
9 0057 Версии Zend Server 6–8.5.x

Чтобы предоставить разрешения конкретному пользователю, просто используйте имя профиля пользователя вместо *PUBLIC в приведенной выше команде.

Убедитесь, что *PUBLIC может обновить сокет FastCGI :

Создайте резервную копию этого файла, а затем отредактируйте его:

Версии Zend Server 2020.x, Zend Server 2021.x и выше
Версии Zend Server 9.1.x, Zend Server 2018.x, Zend Server 2019.x
90 057 Версии 6 — 8.5.x

В конце файла добавьте следующую строку:

Сохраните файл и перезапустите Apache, чтобы изменения вступили в силу.

Для версий IBM i до 7.2, чтобы этот параметр действовал, необходимы PTF. PTF отсутствуют уже довольно давно, поэтому, скорее всего, они есть у большинства клиентов.

No related posts.