Упрощённая регистрация по коду из email

Новости и события Объявления
,
1

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

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

:microscope: Что изменилось

Когда эта функция включена, участники видят более простой процесс:

Screenshot 2026-07-08 at 17.56.16
Screenshot 2026-07-08 at 17.56.16794×376 52.5 KB
:

  1. Они вводят адрес электронной почты и нажимают Продолжить.
  2. Шестизначный код попадает в их почтовый ящик. Они вставляют его (или вводят вручную), и форма отправляется автоматически, когда вводится последняя цифра.
  3. Если у них включена двухфакторная аутентификация (TOTP, резервные коды или ключ безопасности), далее появится стандартный шаг 2FA.

Screenshot 2026-07-08 at 17.58.33
Screenshot 2026-07-08 at 17.58.33726×574 61.1 KB

Несколько деталей, о которых стоит знать: коды действительны в течение 10 минут, истекают после 5 неудачных попыток и могут быть использованы только один раз.

:gear: Как включить одноразовые коды для входа в вашем сообществе

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

Чтобы включить эту функцию, перейдите на страницу Предстоящие изменения в админ-панели (/admin/config/upcoming-changes) и найдите пункт Включить локальный вход по коду. Обновите поле Включено для…, чтобы подключить ваш сайт к этому новому дизайну:

image
image1231×159 51.4 KB

:warning: Перед включением убедитесь, что оба параметра enable_local_logins и enable_local_logins_via_email также установлены в true, так как эту функцию невозможно включить без них. Если вы используете DiscourseConnect (enable_discourse_connect), эта функция не может быть включена.

После включения изменения путь входа по коду появится автоматически.

:game_die: Случайные имена пользователей для новых учетных записей

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

Screenshot 2026-08-27 at 12.15.46
Screenshot 2026-08-27 at 12.15.46456×386 12.6 KB

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

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

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

image
image1048×521 49.3 KB

image
image656×259 18.6 KB

:mega: Что вы думаете?

Теперь ваша очередь: нам бы очень хотелось услышать ваше мнение об этой новой функции. Что вам нравится, а что нет; что работает хорошо, а что можно улучшить?

13 лайков
Current Projects - July 2026
Current Projects - August 2026
Wild signup form (since update?)
Wild signup form (since update?)
10

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

image
image1920×1080 258 KB

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

3 лайка
12

Коды, отправляемые на электронную почту (так называемые «магические ссылки»), — это неплохой вариант, но мягкое подталкивание пользователей к использованию ключей доступа (passkeys) значительно улучшает опыт взаимодействия.

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

Самая распространенная проблема, с которой сталкиваются пользователи магических ссылок, заключается в том, что они думают, что вошли на сайт в своем обычном браузере, но на самом деле авторизация происходит через встроенный браузер приложения. Например, пользователь получает ссылку для входа на свою электронную почту. Он открывает приложение Gmail, нажимает кнопку «Войти в 404 Media», и на его телефоне загружается веб-страница. Но эта страница открывается в веб-браузере Gmail, а не в вашем родном Safari.

Ключи доступа решают эту проблему.

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

Чуть позже, когда администраторы сайта убедятся, что ключи доступа действительно помогают решить проблемы с пользовательским опытом, связанными с магическими ссылками, они могут предложить пользователям добавить ключи доступа после входа в систему, примерно раз в 90 дней или всякий раз, когда они используют функцию кросс-платформенного входа с помощью ключей доступа. Формулировка такого предложения для пользователей устройств Apple может быть следующей: Хотите больше не проверять почту при следующем входе? Настройте ключ доступа, чтобы быстро и безопасно входить в систему с помощью Face ID или Touch ID.

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

2 лайка
13

Привет :waving_hand:

Мне очень нравится этот подход! Однако меня немного беспокоит то, что отображаемое имя нельзя изменить до завершения регистрации. Думаю, было бы здорово добавить возможность изменить его в процессе регистрации.

В моем сообществе я отключил параметр сайта Prioritize username in UX (Приоритет имени пользователя в интерфейсе), что означает, что во всем интерфейсе приоритет отдается Полному имени/Отображаемому имени. Из-за этого автоматически назначенные имена вроде “user21” выглядят на фронтенде довольно плохо, если у пользователя нет немедленной возможности их настроить.

Спасибо!

6 лайков
14

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

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

3 лайка
16

Моя единственная проблема с этой функцией заключается в том, что она удаляет поля имени и имени пользователя со страницы регистрации. Это сделано намеренно? Я не хочу заставлять пользователей копаться в настройках сразу после регистрации, только чтобы задать имя пользователя, отличное от «user63».

3 лайка
17

Этот способ регистрации с проверкой по электронной почте — именно то изменение, которое я всегда хотел!

1 лайк
18

Без этого изменения ссылки «Забыл пароль» и «Отправить мне на почту» имели одинаковый размер. Теперь вторая ссылка больше. Это сделано намеренно?

image
image436×402 13.4 KB
Screenshot 2026-07-20 093447
Screenshot 2026-07-20 093447466×409 13 KB

4 лайка
19

Это было исправлено в

4 лайка
20

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

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

1 лайк
21

Согласен. Эти общие имена пользователей делают взаимодействие с пользователями более запутанным. Поскольку по умолчанию у пользователей есть только 3 дня на изменение имени, я ожидаю, что они часто будут замечать это после истечения этого срока, поэтому сотрудникам нужно будет заниматься переименованием.
Мне очень понравилось, что Offering blank username suggestions rather than ‘UserN’ at signup предотвратило это, например, здесь, на meta. Последний пользователь userXXX был создан 7 января, до того как это исправление было интегрировано. Затем не было новых userXXX, пока эта функция не была включена, и с тех пор появилось 12 новых.

4 лайка
22

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

5 лайков
23

Вы не видите этот шаг при создании аккаунта?

image
image1440×1516 105 KB

24

Это странный цитатник: кажется, что DomMcD процитировал меня, но это не так.

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

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

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

Например, 0102100988082, mohamedasarudeen и user603 — у всех них в качестве имени указано user603.

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

2 лайка
25

Спасибо всем за отчёты, исправление будет объединено совсем скоро:

2 лайка
26

Обновление

Благодаря последней работе @keegan, на этом этапе теперь доступна функция генерации имени пользователя, которая автоматически заполняет поле предложением:

27

Одно, так сказать, UX-пожелание, если это возможно. Вот оно:

IMG_6954
IMG_69541290×731 52.6 KB

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

2 лайка
29

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

4 лайка
30

Совпадением, в этом направлении уже ведётся работа:

https://github.com/discourse/discourse/pull/43138

3 лайка
31

В целом мне нравится эта функция (первый шаг регистрации с использованием только email и кода), но есть некоторые шероховатости:

a) вход и регистрация должны быть отдельными настройками
b) скрытие поля для ввода имени пользователя в форме регистрации должно быть дополнительной опцией, так как имена пользователей по-прежнему являются важной функцией для коммуникации; случайные или счётчики имён выглядят довольно странно
c) странно, но случайные имена пользователей сработали на моём сайте для некоторых регистраций спамеров (неподтверждённые записи пользователей), но не для двух реальных пользователей — оба получили в качестве имён «user1» и «user2», фу. (Не уверен, в чём разница между спамерами и пользователями)
d) для входа можно сделать отдельную кнопку, например, отправляющую email с магической ссылкой и кодом. Не вижу необходимости разделять это.
e) документация должна чётко указывать, что форма для ввода имени пользователя удаляется (или лучше — не удаляется)

1 лайк