Сообщение об успешной регистрации

Обновлено: 05.07.2024

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

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

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

Итак, нам нужны следующие файлы:

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

Всё это будет бессмысленно, если у вас нет соответствующей таблицы в базе данных. Запустите инструмент управления своим СУБД (PhpMyAdmin или командную строку, как удобнее) и выполните в нем следующий запрос:

Наши файлы со сценариями я назову так (все они будут лежать в одном каталоге):

  • database.php;
  • functions.php;
  • login.php;
  • registration.php;
  • index.php;
  • logout.php;
  • checkAuth.php;
  • style.css.

Назначение каждого из них, я уверен, вам понятно. Начнем со скрипта соединения с СУБД. Вы его уже видели. Просто сохраните код этого скрипта в файле с именем database.php . Пользовательские функции мы будем объявлять в файле functions.php . Как это всё будет работать? Неавторизованный пользователь пытается получить доступ к защищенному документу index.php , система проверяет авторизован ли пользователь, если пользователь не авторизован, он переадресовывается на страницу авторизации. На странице авторизации пользователь должен видеть форму авторизации. Давайте сделаем её.

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

Если всё сделано верно, у вас в броузере должно быть следующее:


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


Если всё нормально, в окне вашего броузера, обратившись к документу registration.php, вы должны увидеть примерно такую форму:

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

В скрипте вы должны были заметить еще одну новую функцию — registration() . А мы её еще не объявляли. Давайте сделаем это.

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

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

А теперь давайте создадим код нашей защищенной страницы. Он будет довольно-таки прост.

Как видите, в защищенном документе мы подключаем только один файл — checkAuth.php. Все остальные файлы подключаются уже в других сценариях. Поэтому наш код не выглядит громоздким. Регистрацию и авторизацию пользователей мы организовали. Теперь необходимо позволить пользователям выходить из системы. Для этого мы создадим сценарий в файле logout.php.

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


Перенаправление после удачной регистрации. Как?
Привет. Вот только сел осваивать php и столкнулся с проблемой ответ на которую пока не нашел. Делал.

Не ловится CallBack при успешной регистрации МиниФильтра
Коллеги, приветствую! Пересобираю минифильтр под разные платформы и столкнулся с какой-то багой.

Требуется помощь с формой регистрации.
Здравствуйте, недавно решил создать сайт, и вот пришло время для создания регистрации. Решил.


Всплывающее закрывающееся окно с формой регистрации.
Доброе время суток ! Как сделать всплывающее окно, допустим нажимаем на кнопку регистрации.

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

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

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

Разработка форм регистрации и авторизации

Код регистрационной формы

Ниже приведен HTML-код необходимый для создания формы регистрации. Сохраните его вфайле register.php.

Исходный код страницы авторизации

HTML-код страницы входа в систему приведен ниже. Сохраните его в файле login.php .

CSS-стили для оформления форм

Для улучшения внешнего вида форм примените к ним следующие CSS-стили:

Создание таблицы с учетными данными и подключение к базе данных

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

  1. Порядковый номер ID, который для каждого нового пользователя увеличивается автоматически.
  2. Уникальное имя пользователя.
  3. Адрес электронной почты.
  4. Пароль.

Для быстрого создания таблицы базы данных можно использовать следующий SQL-запрос:

Теперь создайте файл config.php и сохраните в нем приведенный далее код для подключения к базе данных:

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

Исходный код для регистрации пользователей

Сохраните приведенный далее код в начале файла registration.php :

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

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

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

Приведенный далее код должен располагаться в начале файла login.php:

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

Как только мы получаем подтверждение правильности пароля, мы назначаем переменную $_SESSION[‘user_id’] для ID пользователя из базы данных. При необходимости на этом этапе передаются и значения для других переменных.

Ограничение доступа к страницам

Все, что нужно сделать для ограничения или предоставления доступа – это использовать в начале приведенного выше скрипта строку session_start().

Типичные ошибки и способы их решения

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

Некорректное имя переменной

Чаще всего ошибки в работе скрипта связаны с неверными именами переменных – как правило, с использованием букв в неправильном регистре. Именно поэтому крайне важно придерживаться одного и того же шаблона при выборе имен. К примеру, ключи в функции $_POST основаны на значениях, полученных из полей ввода в формах. Это означает, что $_POST[‘USERNAME’] и $_POST[‘username’] получат разные значения.

Переменные сессии не сохраняются при переходах между страницами

Пожалуйста, опубликуйте ваши комментарии по текущей теме статьи. За комментарии, подписки, дизлайки, отклики, лайки огромное вам спасибо!

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

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

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

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

Реализовать схему регистрации, аутентификации и восстановления доступа посредством email и соцсетей.

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

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

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

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

Важное значение имеют соединительные линии (стрелки) на схемах. Они могут быть двух видов: пунктирные (переходы) и сплошные (обмен данными). На основании пунктирных линий можно, например, спроектировать API.

  1. заполнение формы регистрации;
  2. подтверждение email.

Наличие аккаунта

Временный аккаунт

До того, как пользователь не подтвердил свой email, его аккаунт является временным. Это позволяет:

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

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

Подтверждение email классическое: ссылка с GET-параметрами в письме.

Срок жизни подтверждающей ссылки

Повторное подтверждение

При использовании соцсетей схема регистрации во многом использует те же механизмы, что и логин — поэтому здесь они объединены.

Соцсеть не вернула email

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

Объединение аккаунтов

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

Механика логина максимально простая: пользователь вводит email и пароль, после чего сервер проверяет их на соответствие.

Защита от брутфорса

Способ защиты от перебора часто связан с конкретным программным решением или библиотекой, которую вы используете. Могут учитываться сессии, куки, ip-адреса, вспомогательные факторы (вроде включенного JS) и многое другое. Не забывайте про защиту от перебора, это важно.

Восстановление доступа к аккаунту осуществляется в два этапа:

  1. заполнение формы восстановления;
  2. подтверждение: переход из письма и ввод нового пароля.

Подстановка email

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

Отсутствие пароля

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

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

Срок жизни подтверждающей ссылки

Деактивация подтверждающей ссылки

Ну и разумеется, мы не можем позволять пользователям несколько раз сбрасывать пароль по одной и той же ссылке (банальный перехват URL позволит вытворять непозволительные вещи). Поэтому после первого перехода из письма ссылка будет деактивироваться.

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

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

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

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

Тоже не сложно. Как правило, типов полей форм, которые надо валидировать, максимум 3-4, плюс один кастомный, по маске (RegExp). Логично вынести валидацию в отдельную функцию и применять к конкретным полям по необходимости. Благо, для любого фреймворка есть куча готовых решений на эту тему.

Отправка данных

Успешная аутентификация

Функция успешного логина. Подразумевает последующее перенаправление на целевую страницу. В схеме целевая страница представлена профилем с дефолтным состоянием (Nav.Profile, Default), однако хорошим тоном считается запоминать URL, с которого был вызван логин, и возвращать на него пользователя после успешной аутентификации.

Подсказка по логину через соцсети

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

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

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

Очистка данных

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

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

Отправка email

Для многих языков и фреймворков есть готовые нативные решения по отправке email (в том числе, с помощью SMTP). Так как письма могут отправляться из многих частей продукта, логично использовать для этого единую функцию.

Запись успешного входа

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

Проверка на привязанные соцсети

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

Я много пишу про проектирование, разработку и продюсирование IT-проектов, и все свои материалы агрегирую в уютном телеграм-канале, велкам.

Отлично, спасибо большое за инструкцию! То, что надо!

Развели тут хабр

При том не просто хабр, а хабр-торт!

Боги сошли с небес и детально написали ТЗ

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

Насчёт email спорно. Во-первых, логин — это неудобно, все привыкли вводить почты. Во-вторых, email нигде, кроме восстановления, можно и не светить. Да и там, при необходимости, можно повесить защиту от перебора.

Касаемо хэширования да, согласен, запарился. Исправил в статье.

Вы поймите что безопасность и "удобно", быстро и не согласуются между собой. Удобно вам-удобно атакующему. Быстро вам-быстро и атакующему.
email как минимум светится каждый раз когда человек логиниться на ваш сайт, а значит и во всяких запоминалках логинов. Для безопасности пользователя важно важно минимизировать засветку email как только можно.

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

К сожалению (или к счастью), за создание цифровых продуктов отвечают не только одни разработчики и специалисты по цифровой безопасности. Два года назад я в рамках одного проекта проводил исследование: почту в качестве предпочтительной формы регистрации и входа выбрали более 80% респондентов. Предпочтя её и обычному логину, и номеру телефона.

Ну и напоследок. Почта — не самая чувствительная часть персональных данных. Если речь идёт о взломах условных "запоминалок логинов", то там вообще другого уровня проблемы.

Я вас понял, вы как и многие к сожалению побежали по популярной в последнее время дорожке-делать то что хотят пользователи. Только вот в опросе вы забыли упомянуть что риски компреметации аккаунта повышаются, если использовать почту как средство идентификации. И сколько % пользователей после этого все еще выбрали бы почту? Более того-в случае компрометации аккаунта кто будет у пользователя виноват? Он сам думаете? Я думаю пользователь будет обвинять именно вас, и кстати весьма обосновано.

А расскажите, пожалуйста, как повышаются риски компрометации аккаунта, если пользователь использует почту, а не логин? Посредством социнженерии? В 99% случаев нет разницы, email или логин вытаскивать из доверчивых пользователей или из их скомпрометированных устройств.

И да, я, как вы выразились, "побежал по популярной дорожке" удобства пользователей. Почти все цифровые продукты — это бизнес. В наше время невозможно сделать продукт успешным, если он неудобен пользователям. А без успешности у него не будет денег. А без денег нечем будет платить разработчикам и прочим членам проектной команды. Как итог: если продукты не будут удобными, то такие "борцы", как вы, останетесь без работы.

И заметьте, я не призываю полностью отказываться от безопасности или даже серьёзно её снижать. Перечитайте статью.

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

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

Спасибо, с вами все ясно

Инструкция огонь. Делали подобные вещи для проекта реши-пиши с нуля и до всего из статьи доходили со временем ;-) Прочитать бы раньше. Но ещё будем прикручивать соцсети, так что обязательно перечитаю и сделаю подсказки через какую соц сеть логинились, если сессия пропала и в куках помним. Так просто и удобно!

Если пользователь пока не подтвердил email (или соцсеть его не вернула), то ему может быть доступна ограниченная функциональность (например, только просмотр). Блокировать или нет основную функциональность — это уже больше вопрос к основной механике продукта, как и объединение аккаунтов с разными email.

Более того, история с объединением аккаунтов вообще общая и не относится напрямую к регистрации (например, соцсеть может вернуть другой email — и тогда для появления "условий задачи" даже не понадобится отложенное подтверждение).

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

Клёвый вопрос, спасибо. Этот кейс выходит за рамки непосредственно регистрации, но решаем довольно просто.

1. Если пользователь авторизован, и он прикрепляет новую соцсеть, то сначала мы проверяем, вернула ли соцсеть email. Если email не возвращён или email соответствует текущему, просто прикрепляем соцсеть к аккаунту.

5. После подтверждения нового email объединяем аккаунты. Эта механика уже совсем индивидуальная для каждого проекта. Плюс, как и в шаге 2, можем из нового email сделать резервный.

Шаги 3 и 4 можно миксовать, в зависимости от особенностей продукта и целевой аудитории. Понятно, что этот алгоритм подойдёт далеко не всем, но его совершенно точно можно подпилить под себя.

Читайте также: