Бест практис разработки регистрации с подтверждением по email?

Question

[Niksak]

Я пишу проект, на бэке использую node + express ( не поменять уже, всё ).
Моя задача: написать регистрацию с подтверждением аккаунта по email. Я покопал инфы, поспрашивал и пришел сюда тоже спросить кто как видит)
Естественно, это должен быть безопасный и эффективный способ, нужно определиться как и где хранить неактивных юзеров, когда их удалять, удалять ли, чтобы не было казусов что кто-то просто зарегал кучу акков на реальные левые почты и теперь их владельцы не могут зарегаться)

Я спрашивал гпт и смотрел один видос, в общем там одинаковое решение по сути: тут

Еще мне подсказал один человек как можно все это сделать:


В общем, суть:
-Челик ввел email, login, password в форму
-Ему пришло письмо со ссылкой для активации
-Он переходит по ссылке - его редиректит в приложение
-Без активации он не сможет зайти в профиль приложения, никуда дальше формы входа не зайдет

Comments

[Everything_is_bad]

ты напридумывал проблем, просто сделай регистрацию

и пришел сюда тоже спросить кто как видит)

сюда надо уже с конкретной проблемой прибегать, а не просто спросить

[Niksak]

Everything_is_bad, так вопрос просто в том, какой вообще способ народом избранный решать такую задачу
Я так понял, просто через nodemailer отправлять письмо это для пет проектов подойдет только

Кто-то говорил мне очередями делать какими-то)

[Everything_is_bad]

Niksak, а где у тебя в вопросе что-то про проблему с отправкой писем?

[Дмитрий]

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

[Niksak]

Дмитрий, а если представить что проект коммерческий а не 5 человек в год?

[Everything_is_bad]

Niksak, редис это оптимизация, вот будет у тебя проблема, тогда и подумай про него

[Дмитрий]

Niksak, да даже если 5 человек в минуту, это не нужно будет

[maksam07]

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

Так в этом же и суть подтверждения. Если человек может подтвердить почту, значит это его почта. Что значит "владельцы не могут зарегаться"?

[ThunderCat]

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

[maksam07]

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

[ThunderCat]

maksam07, Естественно, как самый очевидный вариант, но логика может быть сильно разной в зависимости от задач, так что выбор остается за разработчиком и бизнесом.

Answer 1

[alexalexes]

1. Активные пользователи хранятся там же, где неактивные пользователи - в нормальной реляционной СУБД, а не редис.
Активный пользователь отличается от неактивного, наличием даты-время подтверждения эл. почты. В этой же записи пользователя в отдельном атрибуте храните сгенерированный хеш-код для подтверждения, который используете в ссылке.
2. В неавторизованном состоянии предусматриваете возможность повторной высылки кода подтверждения на указанный эл. адрес. (Прямо отдельная форма).
3. Любые действия, связанные с высылкой письма должно подтверждаться проверкой пользователя, что он человек (капча, или использование сторонних сервисов проверки).
4. Скрипт, который обрабатывает ссылку подтверждения почты тоже должен иметь защиту от ддоса.
Все.

Comments

[Niksak]

Кроме редис у нас еще mongo

[Everything_is_bad]

mongo

бинго!1

[alexalexes]

Берите postgres/mariadb/любая коммерческая реляционная СУБД. Не играйтесь в детский сад с инструментами кеширования.

[Niksak]

alexalexes, ну монго уже не убрать из проекта(

[Adamos]

Niksak, если это так - это серьезная проблема архитектуры.

[tukreb]

Niksak, почему не убрать? PostgreSQL отлично её заменяет из коробки и даже redis (PostgreSQL) при правильной настройке (там можно настроить чтобы таблицы работали по аналогии с redis). Или вы совершили все ошибки которые возможно и в качестве СУБД ещё и MySQL взяли?

[ThunderCat]

tukreb,

Или вы совершили все ошибки которые возможно и в качестве СУБД ещё и MySQL взяли?

о, снова пришло время субъективных высказываний, преподносимых в форме истины в последней инстанции? ))

Answer 2

[Adamos]

В сущности, проблема обозначена: человек взялся ваять самопис, не познакомившись с готовыми решениями, которые сто лет как написаны и отлажены. В результате медитирует над оптимальной формой руля велосипеда, следующим шагом перегорит от "все сложно" и забросит проект.
Решение: берешь ЛЮБУЮ ВООБЩЕ CMS и изучаешь, как такие базовые проблемы решили до тебя. Не изобретая.

Comments

[Niksak]

Проект пишется с нуля именно, без CMS
Или предлагаешь просто скомуниздить у них решение?

[Adamos]

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

[alexalexes]

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

[Adamos]

alexalexes, для обучения и развития - разумеется.
Но самостоятельно, а не бегая на Тостер с каждой фигней просто потому, что не умеешь посмотреть готовые решения в огромной массе открытого кода.

[Niksak]

Adamos, я глянул открытые решения, но не особо могу выбрать конкретный
Не сильно там уж объясняются важные аспекты типа безопасности и производительности этой фигни

[Adamos]

Niksak, безопасность того, что годами работает на реальных сайтах, обычно подтянута. В отличие от велосипедов.
Про производительность для пет-проекта, который пишется с таким багажом знаний, лучше забыть сразу.
Любой сверхбыстрый движок тут разве что слегка замаскирует ляпы программиста.
Тут нет никакого смысла хвататься за то, что призвано обеспечить производительность хайлоада, стоит использовать самый базовый стек. Вот когда и если на нем, вопреки статистике, будет создано хоть что-нибудь рабочее - тогда... ну, первым делом - переписать на том же базовом стеке то, что получилось очевидно безобразным и нерабочим. А вот где-то пятым-девятым уже пойдут оптимизации небазовыми решениями.