Окно авторизации на php. Форма входа и регистрации с помощью HTML5 и CSS3
Все кто разрабатывает web сайты, рано или поздно сталкивается с такой задачей как авторизация и аутентификация пользователей , реализованная именно с помощью языка программирования, а не с помощью стандарта протокола http. Сегодня мы рассмотрим пример создания простой авторизации с использованием языка программирования PHP, а данные о пользователях будем хранить в базе MySQL.
Приведенный ниже способ является простым или как бы основой для создания нормальной авторизации, но его Вы вполне можете использовать, так как он достаточно хорошо работает, также Вы сами можете улучшить этот способ и внедрить у себя на сайте.
Данный способ основан на сессиях, но я здесь применяю и куки, для того чтобы браузер запоминал пользователя, который аутентифицировался прошлый раз, чтобы каждый раз не вводить логин, можно конечно хранить в куках и пароль, но это не безопасно, даже если он зашифрован. Для того чтобы сессия закончилась, просто закройте браузер и откройте заново.
Создание объектов в базе данных
Переходим к практике. Для начала создадим таблицу хранения данных о пользователях в базе MySQL . Я предлагаю использовать простую структуру таблицы (Вы ее, конечно, можете дополнить чем-нибудь, у меня база называется test, а таблица users ):
CREATE TABLE test.users(user_id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT, user_login VARCHAR(30) NOT NULL, user_password VARCHAR(32) NOT NULL, PRIMARY KEY (user_id)) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_general_ci;
И давайте сразу же добавим одну запись в эту таблицу:
Insert into test.users (user_login, user_password) values ("mylogin","202cb962ac59075b964b07152d234b70")
Итого у нас получилось:
- Логин – mylogin;
- Пароль -;
Мы пароль, конечно же, будем хранить в хешированном виде, так как хранить пароль в открытом виде, мягко сказать, не безопасно. У нас Выше хеш пароля 123, поэтому, когда будем вводить пароль в форму, мы будем забивать именно 123, а не.
Создание формы регистрации
Для того чтобы пользователь мог сам зарегистрироваться, сделайте форму, данные с которой будут посылаться на файл обработки регистрации, т.е. записываться в базу данных. Например, вот самый простой способ:
0) { $error = "Пользователь с таким логином уже есть"; } // Если нет, то добавляем нового пользователя if(!isset($error)) { $login = mysql_real_escape_string(trim(htmlspecialchars($_POST["login"]))); // Убираем пробелы и хешируем пароль $password = md5(trim($_POST["password"])); mysql_query("INSERT INTO users SET user_login="".$login."", user_password="".$password."""); echo "Вы успешно зарегистрировались с логином - ".$login; exit(); } else { // если есть такой логин, то говорим об этом echo $error; } } //по умолчанию данные будут отправляться на этот же файл print <<< html
html; ?>Кстати, при таком способе лучше всего для логина использовать латинские буквы (т.е. английские ), если хотите писать логин на русском, то придется немного корректировать код. Файл можете назвать как угодно (для теста я использовал reg.html ).
Примечание! Для тестирования я использую всего один файл, я его назвал mylogin.html (код файла ниже). Вы можете использовать в своих файлах и называть их как угодно, я здесь описываю сам процесс авторизации, поэтому применить его можно везде. Кстати, во всех файлах придется использовать функцию session_start(); для того чтобы Вы могли проверять авторизован пользователь или нет. И еще один момент, конечно же, пропишите свои настройки подключения к базе данных.
Создание формы авторизации
"."Вы авторизованы
Т.е. мы проверили сессию и можем открыть доступ к определенным данным";
} else {
$login = "";
//проверяем куку, может он уже заходил сюда
if (isset($_COOKIE["CookieMy"])){
$login = htmlspecialchars($_COOKIE["CookieMy"]);
}
//простая формочка
print <<< html
Примечание! Если вдруг у Вас отказывает работать парсер php, т.е. на экран Вам выводится сам код php, то у Вас просто на всего не включена обработка php в файлах html. Настройки делаются в файле конфигурации web сервера httpd.conf (если apache):
AddType application/x-httpd-php .php .html
В IIS в окне «Добавление сопоставления модуля» (Add Module Mapping) добавьте к *.php еще и *.html через запятую. Это если Вы делаете у себя дома на своем web сервере, а если Вы все это делаете у хостера, то Вам придется писать им и просить внести необходимые изменения, у некоторых хостеров они уже сделаны.
Код я прокомментировал, поэтому я думаю, что все должно быть понятно. Еще раз напоминаю во всех файлах, содержимое которых Вы не хотите показывать не авторизованным пользователям, необходимо писать session_start, ну и, наверное, на этом все. Если есть вопросы, задавайте в комментариях. Удачи!
В формате данного урока создадим форму авторизации на CSS , покажу, как подключать шрифтовые иконки, каким образом задавать прозрачность у элементов, задействуем в форме анимированные эффекты при наведение.
Каркас формы в HTML
Первым создаем каркас формы. Открываем заготовку html и пропишем следующий код между тегами.
Создаем блок, который будет являться контейнер для формы. Присвоим ему класс .container , в нем размещаем форму с input Первый input для ввода логина type="text" name="username" placeholder="Введите логин" , второй input type="password" name="password" placeholder="Введите пароль" принимает пароль и за ним кнопка submit . Ниже размещаем надпись для восстановления пароля, сделаем ее простой ссылкой.
Описываем в CSS элементы формы
Затем оформим данные элементы формы. Создадим дополнительную директорию CSS в которой будем размещать файлы стилей. В ней создаем файл style.css и подключаем его к нашей страничке.
Я предлагаю на задний фон поставить изображение, для этого создадим дополнительную директорию img
, и поместим в нее свое изображение. Подключаем картинку в style.css
для body
. Прописываем путь до картинки, выходим с текущей директории, заходим в папочку img
, и далее название картинки.
Body{ background-image: url("../img/bg.png"); }
A{ color: #fff; } a:hover{ text-decoration: none; }
Предадим стили контейнеру с формой .container
. Зададим ширину в 450 пик., и временно установим высоту в 500 пик. Зададим цвет #182134
, и отцентрируем ее посередине экрана margin: 250px auto 0 auto;
. Текст в нутрии блока размещаем по центру, сверху сделаем отступ в 20 пик.
Container{ width:450px; height: 500px; background-color: #182134; margin: 250px auto 0 auto; text-align: center; }
Оформим затем input для ввода логина и пароля. Что бы не затронуть кнопку, отберем их по атрибутам text и password , указываем ширину в 300 пик. , высоту в 50 пик. Текст увеличиваем на 18 пик., сделаем отступы между ними в 25 пик., закруглим углы border-radius: 4px; , текст сдвинем на 10 пик. влево.
Input,input{ width: 300px; height:50px; font-size: 18px; margin-bottom: 25px; border-radius: 4px; padding-left: 10px; }
Затем отцентруем inpyt
, для этого обернем их в дополнительный блок и присвоим класс .dws-input
. Сделаем перенос строки после кнопки, и вверху перед кнопкой вставим картинку с нашим логотипом. Для этого скопируем ее в папку img
, и пропишем к ней путь img src="img/men.png"
.
Далее опишем ее стили. Картинке присвоим ширину и высоту по 120 пик. , затем подымем ее чуть выше формы margin: -60px 0 30px 0; , делаем об водку в 5 пик. border: 5px solid #1a394f; , закругляем углы в 50%.
Container img{ width:120px; height:120px; margin: -60px 0 30px 0; border: 5px solid #1a394f; border-radius: 50%; }
Теперь опишем стили кнопки. Присвоим ей класс .dws-submit , и назначаем ей стили. Назначаем отступы, увеличим текст на 15 пик., делаем его белым, а фон кнопки синим, убираем об водку и сделаем в низу плашку, а также курсор Pointer .
Dws-submit { padding: 13px 30px; margin: 5px 0 20px 0; font-size: 15px; color: #fff; background-color: #2ca8c6; border: none; border-bottom: 4px solid #6ee9fd; cursor: pointer; }
Чтобы отцентровать инпуты и кнопку, поместим их отдельно каждый в свой блок. Опишем стили кнопке при наведении. Делаем плавный переход, цвет кнопки меняем на белый, а в тоже время шрифт будет меняться на темный.
Dws-submit:hover{ transition: all 0.5s; background: #fff; color: #2c536c; }
Сделаем, сверху нашей формы синею плашку, box-shadow: 0 -5px 0 #3adbfd; , и добавим ее к картинке box-shadow: 0 -5px 0 #3adbfd; . Сделаем фон формы немного прозрачнее, для этого пропишем этот цвет в формате RGBA .
Я пользуюсь сервисом w3schools.com , спускаемся вниз до Color Picker , в форму введем наш цвет и преобразуем его в RGB . Копируем, вставляем в стиль контейнера.
Container{ width:450px; height: 500px; background-color: rgba(24, 33, 52, 0.7); margin: 250px auto 0 auto; text-align: center; box-shadow: 0 -5px 0 #3adbfd; } .container img{ width:120px; height:120px; margin: -60px 0 30px 0; border: 5px solid #1a394f; border-radius: 50%; box-shadow: 0 -5px 0 #3adbfd; }
Для эффекта, закруглим нижние углы, для этого пропишем border-radius: 0 0 10px 10px;
.
Добавление шрифтовых иконок
Добавим иконки в виде шрифтов, переходим на сервис fontawesome.io и скачиваем их к себе на компьютер. Распакуем архив, копируем папку fonts, в которой находятся шрифты, и копируем файл стилей в директории css. Затем подключаем стили к страничке.
Отберем иконки для наших инпутов, для этого переходим на страничку Icons , первый подключим стиль для ввода логина, используем user , копируем его код f007 , и описываем его в стилях при помощи псевдоэлемента.
Подключаем шрифты font-family: "FontAwesome"; ,затем саму иконку, позиционируем ее абсолютно поля, увеличим ее на 30 пик, отцентруем и изменим цвет.
Dws-input::before{ font-family: "FontAwesome"; content: "\f007"; position: absolute; font-size: 30px; padding: 10px 0 0 7px; color: #2c536c; }
Немного подвинем текст в input - padding-left: 40px; .
Отберем вторую иконку с названием lock , копируем ее код f023 , и описываем ее стили.
Для этого отбираем второй элемент .dws-input:nth-child(2)::before{}
, и прописываем картинку content: "\f023
";.
Dws-input::before{ font-family: "FontAwesome"; content: "\f007"; position: absolute; font-size: 30px; padding: 10px 0 0 7px; color: #2c536c; } .dws-input:nth-child(2)::before{ content: "\f023"; }
Dws-input:hover::before{ color: #319ebc; transition: all 0.3s; }
А также, стили наведение для инпутов.
Dws-input input:hover{ box-shadow: 0 0 6px 3px rgba(58, 219, 253, 0.35); }
Для удобства обернем их в блок с классом .social
и опишем их стили. Изменим их цвет на белый, увеличим на 20 пик., сделаем шириной в 20 пик., и дадим отступы.
Dws-social i{ color: #fff; font-size: 20px; width: 20px; padding: 10px; }
Затем опишем стили при наведении. Сделаем белый блок, фон иконки изменим на темный, закруглим углы и при наведение отобразим курсор.
Social i:hover{ background-color: #fff; color: #1a394f; border-radius: 5px; cursor: pointer; }
Уберем высоту блока формы, которую задавали в самом начале, а в место ее добавим нижний отступ padding-bottom: 20px; .
В принцыпе и все, получилась довольно симпатичная форма, которую можно подключить на сайт и использовать для авторизации.
Пробуйте сделать на примере данного урока что нибудь свое оригинальное, тренируйтесь, и не забывайте делится данным материалом.
От автора: рано или поздно каждый веб-разработчик сталкивается с задачей по ограничению доступа к некоей странице/страницам или каталогу. Это может быть просто секретная страница на сайте, административная часть сайта или любой другой раздел, доступ к которому мы хотим ограничить и предоставлять только по паролю. Для этого можно, конечно же, воспользоваться средствами сервера. Думаю, на любом современном хостинге есть функция паролирования директории, где можно создать пользователя, назначить ему пароль и, после паролирования директории, доступ к закрытому каталогу будет предоставлен только после правильного ввода логина и пароля. Но иногда хочется написать что-то самому, что-то быстрое, простое, но вместе с тем — надежное…
В этом уроке мы попробуем написать свою простую систему авторизации. У нас будет секретная страница — допустим, это будет страница администратора, доступ к которой мы будем предоставлять только для авторизованного пользователя. Наша система авторизации будет основана на работе механизма сессий. Перед продолжением этого урока я рекомендую Вам ознакомиться с одним из предыдущих своих уроков, в котором мы, в частности, рассматриваем работу сессий — .
Вкратце всю работу с сессиями можно разделить на 3 этапа:
Открытие сессии. На всех страницах, где подразумевается работа с сессиями, обязательно должен быть осуществлен старт сессии функцией session_start().
Регистрация сессионных переменных.
Разрегистрирование сессионных переменных при помощи функции unset() и закрытие сессии функцией session_destroy().
Шаг 1
Итак, для нашей работы создадим 3 файла — Главная страница (index.php), Контакты (contact.php) и Админка (admin.php). Обращаю внимание на то, что расширение файла, к которому мы будем ограничивать доступ должно быть.php. Как Вы догадались, ограничивать доступ мы будем к файлу admin.php. Код всех файлов самый простой — это своеобразное меню в строку со ссылками на другие страницы, и под ним индивидуальный текст каждой страницы, чтобы мы могли отличать их друг от друга. Вот, к примеру, код индексной страницы:
Главная | Контакты | Админка
Это главная страница
Остальные страницы, как я сказал, отличаются от нее только текстом после тега линии. Я не стал делать полноценные страницы с мета-тегами, поскольку наша задача состоит только в ограничении доступа к некоей странице.
Шаг 2
Пока что мы свободно можем ходить по всем страницам, включая страницу админки. Как же мы ограничим к ней доступ? Каков вообще будет алгоритм? Мы будем делать следующее: в самом начале страницы мы будем проверять, есть ли нужная нам метка в сессии или, проще говоря, существует ли определенная сессионная переменная (также можно проверять равно ли значение сессионной переменной определенному значению). Если такой переменной нет, значит пользователь, запрашивающий эту страницу, не авторизован, а значит мы осуществим его редирект на страницу авторизации, где ему будет предложено заполнить форму с именем и паролем. Алгоритм предельно прост — реализуем его. Переходим к файлу admin.php, открываем в самом верху конструкцию PHP и напишем такой код:
session_start () ; if (! $_SESSION [ "admin" ] ) { header ("Location: enter.php" ) ; exit ; |
Давайте теперь прочитаем это код. Во-первых, мы открыли сессию, как Вы помните — это обязательное условие при работе с сессиями. Далее, мы создали простое условие, которое можно прочитать так: «если в массиве $_SESSION не существует элемента admin — будем выполнять блок действий, заключенный в операторные скобки». А в блоке кода мы при помощи функции header() производим редирект пользователя на страницу enter.php (это страница авторизации). После функции header() обязательно завершаем выполнение скрипта при помощи функции exit(). Если же условие не выполнится, т.е., в массиве $_SESSION будет элемент admin — это значит, что пользователь уже успешно авторизован, и мы пропустим блок действия в операторных скобках, т.е., никакого редиректа происходить не будет, и мы покажем запрошенную страницу.
Шаг 3
Теперь нам нужно создать страницу авторизации — enter.php. Для этого скопируем код, к примеру, страницы contact.php, создадим новый файл и вставим в него скопированный код. Файл сохраняем под именем enter.php. Теперь на этой странице напишем простенькую форму для ввода логина и пароля:
Главная | Контакты | Админка
Это страница авторизации.
< p > < a href = "index.php" > Главная< / a > | < a href = "contact.php" > Контакты< / a > | < a href = "admin.php" > Админка< / a > < / p > < hr / > < br / > < form method = "post" > Username : < input type = "text" name = "user" / > < br / > Password : < input type = "password" name = "pass" / > < br / > < input type = "submit" name = "submit" value = "Войти" / > < / form > |
Здесь все просто. В форме 2 поля: поле для ввода логина (ему мы дали имя «user») и поле для пароля (с именем «pass»). Также мы создали кнопку (имя «submit»), по нажатию на которую будут отосланы данные из формы. Данные отсылаются методом post — это мы указали в атрибуте method тега form — и будут обработаны на этой же странице. Теперь мы можем попробовать зайти на страницу админки. Если все сделано без ошибок — мы туда попасть не сможем, а неизменно будем оказываться на странице авторизации.
Замечательно!
Шаг 4
Далее нам нужно написать на странице с формой ее обработчик, который будет принимать данные из формы и сравнивать, совпадают ли логин и пароль из формы с теми, которые есть у нас. Для этого откроем вверху страницы авторизации конструкцию PHP и начнем писать код. Для начала мы должны открыть сессию — ведь именно здесь мы будем создавать метку в сессии, если получены верные логин и пароль. На этой же странице мы будем хранить логин и пароль администратора. Обычно эти данные хранятся в базе данных (БД), но у нас будет только 1 пользователь (администратор), а потому хранить его данные для входа в БД не совсем рационально. Если же пользователей будет не один, т.е., мы, к примеру, пишем проект, в котором имеется регистрация, то, конечно же, без БД в таком случае обойтись будет сложно.
Итак, наш логин будет «admin» и хранить мы его будем в переменной $admin. Пароль будет «mypass» и он будет храниться в переменной $pass. Но хранить пароли в открытом виде не принято — это противоречит принципам безопасности. Хранить пароль мы будем в зашифрованном виде, а зашифровать его нам поможет функция md5(). Эта функция шифрует строку по специальному алгоритму, и на выходе мы получаем строку из 32 символов (ее называют хеш). Если мы зашифруем строку «mypass» (это можно сделать, например, в файле contact.php):
echo md5 ("mypass" ) ; |
то на выходе получим строку «a029d0df84eb5549c641e04a9ef389e5″ — это и будет наш зашифрованный пароль. Пока что код страницы авторизации будет таким:
Главная | Контакты | Админка
Это страница авторизации.
session_start () ; $admin = "admin" ; $pass = "a029d0df84eb5549c641e04a9ef389e5" ; < p > < a href = "index.php" > Главная< / a > | < a href = "contact.php" > Контакты< / a > | < a href = "admin.php" > Админка< / a > < / p > < hr / > < br / > < form method = "post" > Username : < input type = "text" name = "user" / > < br / > Password : < input type = "password" name = "pass" / > < br / > < input type = "submit" name = "submit" value = "Войти" / > < / form > |
Шаг 5
Теперь проверим то, что мы получили из формы с тем, что у нас есть в переменных с логином и паролем. Делать это мы будем по условию — только в том случае, если нажата кнопка формы. Как мы можем это проверить? У кнопки есть имя («submit»), а данные мы передаем методом post. Соответственно, мы можем просто проверить, существует ли элемент submit в массиве $_POST. Если есть — кнопка была нажата, и мы будем выполнять действия по проверке присланных данных, иначе — ничего делать не будем. После объявления логина и пароля пишем условие:
if($_POST["submit"]){ if($admin == $_POST["user"] AND $pass == md5($_POST["pass"])){ $_SESSION["admin"] = $admin; header("Location: admin.php"); exit; }else echo "
Логин или пароль неверны!
"; }if ($ _POST [ "submit" ] ) { if ($ admin == $ _POST [ "user" ] AND $ pass == md5 ($ _POST [ "pass" ] ) ) { $ _SESSION [ "admin" ] = $ admin ; exit ; }
else
echo
" Логин или пароль неверны! |
Условие по проверке логина и пароля мы сделали как бы двойным. Сделано это при помощи логического оператора AND (его также можно записать таким образом — «&&»). Условие можно прочитать так: «если(переменная $admin равна элементу user в массиве $_POST И переменная $pass равна хешу элемента pass в массиве $_POST) то {выполняем блок действий}else выводим на экран текст ‘Логин или пароль неверны!’
Если же пара логин-пароль совпадает, то мы регистрируем сессионную переменную $_SESSION["admin"] и перенаправляем пользователя на страницу админки — admin.php.
Попробуем теперь протестировать то, что мы уже создали. Если мы введем заведомо ложные логин и пароль, то получим предупреждающее сообщение, что «Логин или пароль неверны!». Попробуем теперь ввести правильные данные для входа. Если мы нигде не ошиблись, то после нажатия на кнопку «Войти» мы окажемся на странице админки.
Шаг 6
Теперь осталось дописать некоторые мелочи. К примеру, мы сейчас авторизованы в системе, но если мы введем в адресной строке адрес страницы авторизации, то спокойно попадем на нее и увидим форму авторизации. Такого быть не должно — форму должен видеть только неавторизованный пользователь. Как мы можем исправить это? Помним, что на странице admin.php мы проверяли, есть ли метка в сессии. Если ее нет — мы переводили пользователя на страницу авторизации. Здесь мы можем сделать то же самое, только наоборот. Т.е., мы также проверяем, есть ли метка в сессии. Только теперь мы будем переводить пользователя на страницу админки, если такая метка есть. Это, в принципе, логично. Если есть метка, значит пользователь уже авторизован, и мы его можем перевести на страницу админки. На странице enter.php после старта сессии допишем такой код:
if($_SESSION["admin"]){ header("Location: admin.php"); exit; }
if ($ _SESSION [ "admin" ] ) { header ("Location: admin.php" ) ; exit ; |
Теперь если авторизованный пользователь попробует ввести в адресную строку имя страницы авторизации — он будет переведен на страницу админки. Не авторизованный пользователь же сможет свободно попасть на страницу авторизации.
Шаг 7
Следующий момент, который нам нужно предусмотреть — это реализация выхода авторизованного пользователя, т.е., допустим, администратор закончил свою работу и ему нужно выйти, чтобы никто посторонний не смог работать под его учетной записью. Для этого добавим на странице admin.php ссылку «Выход». Ссылка будет вести на эту же страницу, только к ней будет добавлен нужный нам параметр. Параметр добавляется при помощи вопросительного знака:
Выход
< a href = "admin.php?do=logout" > Выход< / a > |
Эту ссылку можно поставить в том месте, в котором нам нужно — я поставлю ее после текста страницы. Относительно параметра — он будет передан методом GET (вспоминаем, что из формы мы передавали данные вторым параметром — POST). При использовании этого метода данные присоединяются к адресу в адресной строке и отделены от адреса как раз вопросительным знаком. Мы передаем один параметр — do — и при этом присвоили ему значение «logout». Как теперь мы можем разавторизовать пользователя? Очень просто — здесь нам помогут второй и третий этапы при работе с сессиями. При загрузке страницы мы можем проверить значение элемента do из массива $_GET. Если оно будет равно строке «logout» — мы просто разрегистрируем сессионную переменную $_SESSION["admin"] и разрушим сессию. Соответственно, метки в сессии после этого не будет и в следующем блоке, где мы проверяем наличие метки, пользователь будет перенаправлен на страницу авторизации. Все просто.
Итак, есть задача — сделать регистрацию в системе и возможность авторизации. Как это делать? Начнем по порядку.
Регистрация на php
Тут все просто. Делается хранилище данных для пользователей. Обычно это таблица БД. В нее входят такие поля как id, username и password. Остальные поля опциональны. Вы можете собирать e-mail пользователей, их адреса, возможные ip, время выхода в сеть, кодовые слова от банковских карт, секретные вопросы...
В общем, главное — это пара логин-пароль.
Первый важный момент — нельзя хранить пароли пользователей в открытом виде. То есть, как текст. Нельзя потому что если к БД получит доступ кто-то посторонний — он получит базу логин-паролей пользователей, что вряд ли им понравится. А если учесть что логин-пароль у многих пользователей на разных сервисах одни и те же — это ставит под угрозу и личные данные и финансы и личную переписку и все что угодно.
Пароли надо хранить в виде хэша. Хэширование — это операция, которая превращает исходные данные в какой-то слепок известной длины. Это хорошо тем, что слепок уникален. То есть, если мы изменим в исходных данных хотя бы один символ — слепок на выходе операции хэширования получится совершенно, до неузнаваемости другим. Операция хэширования необратима, то есть, из этого слепка не получится развернуть исходные данные. Этим оно и отличается от шифрования.
В MySQL и php есть одна и та же распространенная и безопасная функция хэширования — md5. Этот алгоритм принимает данные и отдает отпечаток.
Итак, мы получаем данные от пользователя, проверяем не пустые ли они, не содержат ли всяких ненужных нам символов (не ограничивайте пользователей слишком сильно). И теперь делаем запрос вроде этого:
INSERT INTO `users` (`id`,`username`,`password`) VALUES("",$quoted_username,MD5($quoted_password));
Обратите внимание — я специально обозвал переменные $quoted_ потому что перед запихиванием их в запрос их обязательно надо отэскейпить функцией mysql_real_escape_string(). Так как эта функция очень часто используется, а пишется очень длинно (люблю архитекторов пхп) — я рекомендую запихать ее в свою оболочку. Например, так:
Function quote($var) { return mysql_real_escape_string($var); }
Авторизация на php
Мы добавили нового пользователя и теперь он авторизуется. Мы рисуем ему форму логина-пароля и ловим его данные. Что дальше? Ведь пароль нам пришел в открытом виде, а в базе — хэш пароля. Придется конвертировать пароль в хэш, потом сравнивать их? Не, можно сделать проще — в один запрос.
SELECT * FROM `users` WHERE `login`=$qoted_login AND `password`=MD5($quoted_password);
Если запрос вернет строку — это будет строка с данными пользователя. Если нет — такого пользователя в таблице нет. Данные пользователя очень нам пригодятся — стоит их получить в ассоциативный массив.
Запомнить пользователя
Теперь нам надо запомнить что пользователь авторизован и точно знать кто это. Первое что приходит в голову — использовать для этого куки. Действительно — запихать в куки логин и id пользователя и всегда знать кто запрашивает страницу в данный момент.
Но это порочная практика. Почему? Потому что куки — это файл, который хранится у пользователя в браузере и данные из этого файла передаются серверу в каждом запросе. Во-первых, они передаются как текст, а это значит — их легко перехватить. Во-вторых, это простой текст, посылаемый пользователем. Поэтому его можно буквально переписать. Например, если мы решили хранить в куках логин пользователя "Вася" он может открыть управление куками в своем браузере, найти нужную куку и исправить ее на, скажем, "Admin". И все. Теперь при каждом запросе мы будем получать куку, которая нам будет сообщять юзернейм пользователя — "Admin".
Поэтому безопаснее хранить все данные на сервере в недоступном из веба месте. В какой-то папке, к которой нельзя получить доступ из браузера. В эту папку нужно писать все данные о пользователе и читать их оттуда каждый раз, когда он запрашивает документ. Чтобы узнать какому пользователю принадлежит какой файл данных — надо обзывать файл уникальным именем и вот это имя кидать уже пользователю в куки. Таким образом, пользователь не сможет узнать как называется файл для пользователя Admin — этот файл генерирует система на сервере. И это позволяет таскать от документа к документу хоть пароли в открытом виде.
То что я описал — это механизм сессии . В Perl, например, для использования сессий нужно загружать модули. А в php сессии поддерживаются из коробки. Фактически, все что вам нужно знать — это функция session_start() и массив $_SESSION. Это все. Сейчас расскажу.
В каждом скрипте, где вы будете писать в сессию или читать из нее, вам надо до того, как вы выведете какую-то информацию вызвать функцию session_start(). Это запустит сессию. Эта функция создаст файл сессии если его нет или прочитает его если скрипту была передана специальная кука.
Чтобы записать в сессию данные нужно просто записать их в массив $_SESSION. Сейчас нам надо помнить id юзера.
$_SESSION["userid"] = $userinfo["id"];
Все. Теперь каждый раз когда пользователь будет запрашивать скрипт, который использует сессии — вам будет доступно значение элемента $_SESSION["userid"].
Поэтому когда пользователь ввел логин и пароль, мы получили его данные из БД, что подтверждает что такой пользователь есть в нашей базе данных, мы запоминаем его в сессии.
Узнать авторизован ли пользователь
Ну это уж проще простого! Теперь, когда вы знаете как работают сессии — узнать авторизован ли пользователь — дело одной строки. Вот она:
If(isset($_SESSION["userid"])) { print "пользователь авторизован"; }
Если в сессии определен id пользователя, значит он уже прошел авторизацию. Но как узнать какой именно это пользователь? Какой его логин? Дата рождения? Кодовое слово для банковской карты? Девичья фамилия матери?
Ну очевидно — сделать один запрос к таблице users. У нас же есть id этого пользователя.
SELECT * FROM `users` WHERE `id`=$quoted_userid
Как разлогинить пользователя, сделать выход
Ну это уж совсем просто. Если мы определяем авторизован ли пользователь по наличию userid в сессии, то чтобы его разлогинить нужно удалить его оттуда. Делается так:
Unset($_SESSION["userid"]);
Еще можно убить сессию для верности. Это очистит куку у пользователя и уничтожит файл сессии на сервере. При этом из нее пропадут все данные. Делается так:
Session_destroy();
На этом все. Если остались какие-то вопросы — не стесняйтесь обращаться. Более того, вы можете обратиться ко мне по icq или почте и попросить помочь с чем-нибудь. Я обычно не отказываю. Если помощь потребуется серьезная — я могу попросить небольшую оплату. Кроме того, я могу дистанционно учить вас делать сайты! Вот такой я коуч и гуру:) А если вы хотите получать уроки и трюки просто так, бесплатно — подпишитесь на RSS моего блога .
Спонсор этого поста — ibooknet.ru, который предлагает ремонт ноутбуков по приятным ценам. Лично мой ноут в порядке и надеюсь, мне не придется его чинить. Чего и вам желаю.
Авторизация и регистрация – одни из важнейших функций любого сайта, во многом определяющие лицо ресурса. От доступности и простоты регистрации напрямую зависит количество пользователей в вашей базе, а легкость авторизации кардинальным образом влияет на UX и наличие у пользователя желания продолжать с вами взаимоотношения. Также простые, понятные и безупречно функционирующие формы избавят вас от шквала писем в техническую поддержку, которые непременно станут для вас головной болью в случае, если процесс регистрации и авторизации на вашем сайте остается проблемным и сложным при достаточно большом количестве пользователей.
По этой причине мы уже не раз обсуждали вопрос о формах регистрации/авторизации, причем как в , так и .
В сегодняшнем материале мы обсудим 10 важных и актуальных подходов, комплексное использование которых позволит создавать формы с высокими показателями юзабилити и, что немаловажно, accessibility . Для читателей, сталкивающихся с этим термином впервые, поясним – аксессибилити есть степень доступности сервиса или сайта для людей с ограниченными возможностями, начиная с пользователей, имеющих нарушенное восприятие цвета, и заканчивая теми, кто не вполне хорошо и точно может управлять мышкой. Кстати, одна из следующих статей будет всецело посвящена теме аксессибилити, так как пользователи, веб-разработчики и оптимизаторы в рунете пока еще плохо знакомы с этим понятием и сопутствующими подходами, а в свете тенденций развития русскоязычного сегмента сети, вопрос о доступности сайтов для людей с ограниченными возможностями становится острым и актуальным.
1. Лучший способ авторизации – это ее отсутствие.
Да, наш первый тезис является банальной и основной истиной UX – чем меньше действий требуется от пользователя, тем лучше. Зачастую, пользуясь некоторыми сайтами, у меня возникает вопрос: «Почему я должен регистрироваться здесь ради того, чтобы разово воспользоваться определенной услугой?». И хотя подобных сайтов, обязывающих вас регистрироваться при отсутствии на то весомых причин, становится меньше, на многих eCommerce сайтах до сих пор можно встретить регистрацию, единственная задача которой заключается в том, чтобы осложнить пользователю жизнь. Это, в первую очередь, относится к разнообразным онлайн-магазинам, требующим от вас регистрации даже для разового приобретения какой-то сущей мелочи.
Итак, для начала убедитесь, что вам действительно нужна регистрация пользователя для того, чтобы обеспечить ему подобающий сервис и полную функциональность. Если это так, то в первую очередь рассмотрите наиболее простой и быстрый способ авторизации, а именно использование модулей социальных сетей, повсеместно распространенных в сети на данный момент и обеспечивающих аутентификацию пользователя в один клик. И если еще несколько лет назад в ответ на предложение использовать модули социальных сетей можно было возразить, что еще не все пользователи ушли в социальные сети и сервисы, то сейчас абсолютное, подавляющее большинство пользователей имеют аккаунт в том или ином сервисе.
Существует большое количество крайне популярных сервисов, охватывающих миллионы пользователей по всему миру. Есть очень большая вероятность, что у вашего среднестатистического пользователя есть аккаунт по меньшей мере в одном из всех представленных сервисов. А представить вы можете действительно много: начиная от традиционного Facebook и заканчивая Yahoo , Amazon и GitHub .
Второе устойчивое возражение против социальных модулей, ранее встречавшееся в процессе веб-разработки, заключалось в опасениях пользователей относительно соблюдения сайтом конфиденциальности и безопасности личных данных, которые пользователь сообщает сайту автоматически, идентифицируя свою личность через один из аккаунтов соцсети. На данный момент, вместе с распространением и беспрецедентной интеграцией социальных сервисов в нашу повседневную жизнь, подобные страхи среди пользователей встречаются все реже, в то время как практически автоматическое кликанье по кнопкам авторизации через социальные сети стало постоянной практикой.
2. Электронная почта должна быть альтернативой любому другому идентификатору пользователя.
В отличие от различных имен и никнеймов, которые часто пользователями забываются, свою почту в большинстве случаев человек помнит всегда. Признаться, мне всегда поднимает настроение сайт, который не слишком требователен ко мне и который готов принять как мое уникальное имя, указанное при регистрации, так и указанную при регистрации почту. В целом, это просто замечательная идея – дать возможность пользователю авторизироваться как с помощью почты, так и с помощью уникального имени. Большой плюс такого подхода во многом связан с тем, что электронная почта и пароль – это крепкая связка, живущая в сознании пользователя. К ней он обращается каждый раз при регистрации на очередном сайте, так почему бы не развить это логичное сочетание и не дать возможность воспользоваться им и при авторизации?
Возможность ввести свою почту в поле user – самое красноречивое проявление заботы о пользователе на этапе авторизации.
Кроме того, с электронной почтой пользователя также связан еще один важный момент – во время процедуры восстановления доступа к сайту при забытом пароле, не делайте обязательным указание уникального имени пользователя – в отличие от почты, оно действительно очень часто забывается.
3. Возможность быстрого переключения между формами авторизации и регистрации.
Достаточно логичным будет расположение форм ввода регистрации и авторизации рядом друг с другом. И хотя они обладают разными функциями и алгоритмом действий, между ними все-таки есть определенная концептуальная схожесть. Компактно расположив формы регистрации и авторизации рядом, а также обеспечив легкий переход между ними (в один клик) вы ощутимо улучшите юзабилити сайта. Кроме того, хорошим способом реализации будет размещение двух кнопок «Регистрация» и «Вход» рядом друг с другом, при клике по которым основная форма будет отображаться либо в форме всплывающего окна, либо выдвигающейся панели.
Максимально компактное и близкое расположение форм регистрации и входа на сайте журнала The Verge .
4. Простой и лаконичный язык.
Несмотря на то, что с используемой терминологией в рунете в последнее время все стало значительно лучше, неясные формулировки и неоднозначные слова все еще можно встретить на кнопках, обозначающих такие простые и тривиальные вещи, как регистрация и авторизация.
Так или иначе, существует несколько разных подходов к выбору надписей на кнопках. Определенно, в большинстве случаев наиболее оправданным является использование лаконичных и однозначных надписей, таких как «Вход», «Войти», «Создать», «Присоединиться» и «Зарегистрироваться». Однако если вы стремитесь создать определенный эффект, то вполне допустимо уходить от лаконичных формулировок к более красочным, таким как «Стать участником», «Войти в мир» и так далее.
Стоит заметить, что при наличии времени и ресурсов проведение A\B тестирования всегда будет полезным.
В качестве примера того, как формируются и меняются пользовательские предпочтения, можно привести опрос Джефа Атвуд а, демонстрирующий популярность различных способов обозначения кнопки авторизации в Соединенных Штатах и Великобритании. Надеемся, что скоро подобная аналитика станет привычной и для рунета.
« Sign In » все чаще используется вместо любых других формулировок.
5. Совместимость форм авторизации с менеджерами паролей различных браузеров.
Менеджеры паролей, интегрированные в браузеры – великое изобретение, колоссально облегчающее использование интернета. Они стали настолько привычной частью нашей повседневной жизни, что мы давно перестали думать о них как о таковых. Мы просто воспринимаем как должное тот факт, что после единичной авторизации на каком-либо сайте нам не придется делать это повторно, мы привыкли видеть формы, заполненные автоматически, и мы начинаем чувствовать себя очень некомфортно, когда обнаруживаем, что форма на сайте, на котором мы уже авторизовывались, оказывается пустой.
Учитывая все это, тестирование формы авторизации с менеджерами паролей различных браузеров – необходимость, которой нельзя пренебрегать. Конечно, кроме интегрированных в браузер менеджеров пользователи вполне могут пользоваться и сторонними менеджерами, но, как правило, при условии, что ваша форма корректно взаимодействует со всеми широко распространенными браузерами, она будет корректно заполняться и сторонним менеджером паролей.
6. Предупреждение и автоматическое исправление ошибок ввода.
Пользователи очень часто делают ошибки при заполнении форм. Характерно, что часто ошибки, сделанные пользователем, являются для него неочевидными, даже если это банальный ввод с неправильной раскладкой или пропущенная буква в пароле. Работать с пользовательскими ошибками мы должны сразу в двух направлениях – внятно оповещать пользователя, обозначая ошибки, и автоматически исправлять то, что возможно исправить.
Что касается оповещений, то набор из предупреждения о включенном Caps Lock, неправильной раскладке или недопустимых символах является базовым – пренебрегать им никак нельзя, ради обеспечения комфорта пользователя вы должны указывать на все без исключения ошибки.
Исправление опечаток и ошибок ввода в автоматическом режиме – достаточно неоднозначная и спорная тема. Наиболее корректно автоматическое исправление в формах может работать с опечатками при указании пользователем электронной почты. Пропущенные буквы в домене или отсутствие точки вполне можно исправлять при помощи автоматического алгоритма, не опасаясь исправить что-либо, введенное пользователем правильно.
7. Стоит ли принуждать пользователей к выбору “подходящего” пароля?
Это еще один вопрос, вызывающий споры среди веб-разработчиков. Для начала следует признать, что, несмотря на все предупреждения, средний пользователь по-прежнему не придает должного значения придумыванию устойчивого и сложного пароля. Как быть с этим фактом – команда каждого сайта решает сама. Можно наблюдать, как по-разному ведут себя формы регистрации на различных сайтах, когда вопрос заходит о вводе пароля. Какие-то формы абсолютно не требовательны к пользователю и принципиально не обременяют его необходимостью соблюдать какие-либо правила, другие – напротив, делают все, чтобы заставить пользователя придумать действительно надежный пароль.
Выбирать, какой подход вам следует использовать, нужно исходя из характера вашего проекта и того, насколько он связан с хранением личных данных пользователя. Если ваш сайт обладает выраженной развлекательной направленностью и аккаунт пользователя не представляет особой ценности для сторонних лиц, то, соответственно, для вас нет никакой необходимости устанавливать строгие правила ввода пароля.
Если же деятельность вашего сайта связана с хранением личных данных и, вероятно, с осуществлением критически важных действий со стороны пользователя, включая финансовые операции, то в таком случае вам придется в той или иной степени проконтролировать пользователя на стадии ввода пароля.
Существует несколько различных способов контролировать придумывание пользователем пароля. Самый простой – использовать один из алгоритмов, анализирующих сложность пароля и сообщающих пользователю о степени сложности и защищенности придуманной комбинации. В то же время, алгоритм вполне может устанавливать некий критический порог, который пользователь должен преодолеть, иначе пароль будет считаться слишком простым и не будет принят системой. Этот подход широко используется на самых разнообразных сайтах.
Классическое сопровождение ввода цветовой индикацией на примере Яндекс.Почты.
Кроме контроля сложности и ограничения минимального количества символов, применяется также еще один довольно любопытный способ, заключающийся в анализе и сопоставлении пользовательского пароля с базой самый популярных паролей в мире , насчитывающей 10 тысяч комбинаций. В случае если вводимый пользователем пароль не оригинален и является одним из самых распространенных, то пользователь получает соответствующее предупреждение и предложение выбрать другую комбинацию.
« That password is too common » – оповещение на Discourse , сообщающее о том, что выбранный пользователем пароль слишком простой и распространенный.
Тем не менее, обратная сторона все подобных действий, направленных на «воспитание» пользователя – практически гарантированное раздражение от опытных пользователей, трезво оценивающих ситуацию и принимающих самостоятельно решение о том, стоит ли в данном случае обойтись простым, символическим паролем, или же необходимо использовать более сложный. По этой причине, вам необходимо взвешенно и последовательно выстраивать политику оценки пользовательских паролей – крайности в этом вопросе могут обернуться как массовым взломом аккаунтов ваших пользователей (и, как следствие, невероятная нагрузка на вашу службу поддержки), так и раздражением и уходом посетителей, которые устали предлагать вашему алгоритму подходящие пароли.
8. Оставляйте возможность переключаться между полями ввода с помощью клавиши «Tab» и выделяйте элементы при таком переключении.
Да, несмотря ни на что, пользователи, все еще переключающиеся между полями формы при помощи клавиши «Tab», еще живы и вполне активны. К слову, автор этой статьи сам частенько пользуется Tab`ом при заполнении различных форм. И, между прочим, как горячая клавиша, Tab здорово ускоряет работу.
Веб-разработчикам не стоит забывать про наше существование – обязательно тестируйте свои формы на корректный отклик на клавишу Tab. И помните, что кроме того, что такое переключение между формами само по себе должно иметь место, вы также должны позаботиться о достаточном визуальном выделении активных элементов.
Фокусировка при переключении Tab `ом в Firefox и Chrome .
9. Как правильно ограничивать количество попыток авторизации или восстановления доступа к аккаунту.
Рано или поздно, но множественные попытки авторизации или восстановления пароля следует останавливать. Можно снисходительно отнестись к 5 или даже 10 попыткам, однако их настойчивое продолжение должно вас насторожить. С дальнейшими операциями по аутентификации, регистрации или восстановлению аккаунта вы должны работать. Самый очевидный способ – после N-нного количества попыток предложить пользователю (или тому, кто скрывается под маской пользователя) ввести капчу, дабы отсеять ботов. Кроме того, хорошим способом является блокировка аккаунта на определенное время при провале множественных попыток авторизации и всех остальных аналогичных действий. Обратите внимание, что аккуратность в этом подходе относится не только к необходимости дать пользователю возможность ошибиться действительно достаточное количество раз, но и к умеренному времени блокировки. Первая блокировка, которую вы будете вынуждены осуществить, не должна быть слишком длительной – просто предупредите в нужный момент того, кто пытается осуществить действие с аккаунтом, что следующая попытка обернется блокировкой на определенное время. Если по истечению этого времени пользователь, взломщик или бот продолжит делать ошибки, то вы вполне можете последовательно увеличивать временной интервал до внушительных значений.
Стоит заметить, что подобные техники с последовательно увеличивающейся временной блокировкой должны быть привязаны к одному IP – не забывайте, что после безуспешных действий злоумышленника, приведших к блокировке, вашим сайтом вполне может воспользоваться настоящий пользователь, IP которого будет, разумеется, другим.
10. Помните о том, что обозначать ошибки одним лишь цветом может быть недостаточно.
Во многом, вопрос выделения сделанных пользователем ошибок дополнительными средствами, не относящимися к привычному цветовому обозначению, зависит от масштабов вашего проекта и количества существующей и потенциальной аудитории. Дело в том, что расстройства цветового восприятия у пользователей распространены шире, чем мы привыкли о них думать . Уже каждый 12-ый пользователь мужского пола является дальтоником, а каждый 30-ый, вне зависимости от пола, обладает плохим зрением. Вам может показаться, что эти показатели не критичны и таких особенных пользователей у вас должно быть немного, однако при достижении определенного критического количества зарегистрированных посетителей, вы неизбежно будете иметь дело с такими людьми. Будет здорово, если вы уделите им немного внимания и облегчите их задачи.
Говоря о дополнительных средствах, которыми можно обозначить сделанные пользователем ошибки, мы имеем в виду такие простые символы, как треугольник с восклицательным знаком, заметный крест рядом с полем, содержащим ошибку, и другие подобные визуальные обозначения. Для того чтобы получить примерное представление о важности таких обозначений для людей, имеющих нарушенное восприятие цвета, рассмотрим характерный пример:
Регистрационная форма PayPal в черно-белом виде.
При анализе данного скриншота регистрационной формы PayPal, переведенной в ч\б режим, наше внимание приковывает, в первую очередеь, треугольник с восклицательным знаком, размещенный в поле капчи. Судя по общей картине, можно сделать вывод, что пользователь забыл ввести лишь капчу, и что с остальными полями все в порядке (вне зависимости от того, заполнены они или нет).
Регистрационная форма PayPal в полноцветном режиме.
Как мы видим, в полноцветной реальности соответствующим образом обозначены все поля, а не только поле для капчи. Однако, тот самый треугольник, который в любом случае сообщит посетителю с расстройством восприятия цвета об ошибке, находится только в одном поле. Примечательно, что эта неявная, и, казалось бы, совершенно не бросающаяся в глаза ошибка была в дальнейшем устранена оптимизаторами:
Новая регистрационная форма PayPal однозначным образом сообщает пользователю об ошибке вне зависимости от того, способен ли он различать цвета.
Как и подход к дизайну в целом, способы создания современных и актуальных регистрационных форм постоянно претерпевают изменения. Несмотря на то, что такая сфера веб-разработки, как формы авторизации и регистрации, обладает устоявшимися правилами и традициями, сами подходы к созданию этих форм постоянно меняются, так же как меняется сам пользовательский опыт и пользовательское восприятие. Постоянно отслеживая изменения пользовательского поведения и тех тенденций, которые формируют сами веб-разработчики и оптимизаторы, вы всегда сможете сохранять все составные части своего проекта, в том числе и формы регистрации и авторизации, актуальными и легко доступными для пользователя. А мы, в свою очередь, будем продолжать держать вас в курсе самых последних трендов в проектировании и оптимизации сайтов. Желаем вам высоких конверсий и больших пользовательских аудиторий!