Как сделать подтверждение по email

Обновлено: 07.07.2024

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

Моды для сервера

Огромный выбор различных модификаций для Вашего сервера. Пролистайте эти темы! Возможно именно там Вы найдете то, что искали уже давно.

San Andreas Multiplayer Mobile

Хотите разнообразить свою игру в San Andreas для телефона? Смелее в наш раздел. Играйте с удовольствием

f0Re3t

Заблокирован

[hide=15]Всем привет. Многие задавались вопросом как сделать подтверждение регистрации через электронную почту. Так как я сегодня добрый xD, я вам расскажу как это сделать. Для начала в информацию об игроке (enum) мы добавляем новую переменную pCode (название можете любое). Дальше в public OnPlayerConnect мы добавляем обнуление переменной: Player[playerid][pCode] = 0 (заменяем на своё, так как у некоторых PlayerInfo). Теперь нам нужно скачать специальный Include:

Размер: 41,7 Мб. + 44,3 Мб.

Длительность: 32 мин.

Данный видеоурок посвящен созданию функции подтверждения регистрации по Email.

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

Сперва нам нужно будет создать в таблице пользователей два новых поля. В одном из них мы будем хранить статус пользователя (ожидает активации /активирован).

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

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

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

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

Все это и некоторые другие моменты мы разберем в деталях в видеоуроках.

P.S. Хотите двигаться дальше в освоении PHP? Обратите внимание на премиум-уроки по различным аспектам сайтостроения, включая программирование на PHP, а также на бесплатный курс по созданию своей CMS-системы на PHP с нуля. Все это поможет вам быстрее и проще освоить этот мощный язык веб-разработки:

Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!

Приветственное письмо Double Opt-In содержит в себе ссылку, которая позволяет пользователю подтвердить свой электронный адрес для получения рассылок. Подтверждение пользователем своего адреса позволяет повысить доставляемость рассылок.

Приветственное письмо double-opt-in сегменту пользователей

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

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

Как запросить подтверждение прочтения

  1. Откройте Gmail на компьютере.
  2. Нажмите Написать.
  3. Напишите письмо.
  4. В правом нижнем углу нажмите на значок "Ещё" Запросить уведомление о прочтении.
  5. Отправьте письмо.

Как отправлять подтверждение прочтения

Что делать, если подтверждения не приходят

Подтверждения прочтения поддерживаются большинством почтовых систем, но вы не будете получать их в следующих ситуациях:

Подтверждения не являются гарантией доставки

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

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

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

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

Реализовать схему регистрации, аутентификации и восстановления доступа посредством 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 можно миксовать, в зависимости от особенностей продукта и целевой аудитории. Понятно, что этот алгоритм подойдёт далеко не всем, но его совершенно точно можно подпилить под себя.

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