Упрощенная регистрация аккаунта с помощью кодов по электронной почте

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

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

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

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

:

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

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

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

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

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

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

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

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

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

8 лайков

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

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

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

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

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

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

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

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

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

2 лайка

Привет :waving_hand:

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

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

Спасибо!

5 лайков

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

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

3 лайка

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

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

1 лайк

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

1 лайк