Сейчас сообщества Discourse могут позволять пользователям входить в систему с помощью короткого кода, отправленного на электронную почту, вместо магической ссылки. Это обеспечивает процесс входа без пароля, который многим будет знаком по другим SaaS-платформам, и работает в связке с вашей существующей настройкой двухфакторной аутентификации.
В этой теме мы рассмотрим основные изменения и расскажем, как вы можете начать использовать эту функцию уже сегодня.
Что изменилось
Когда эта функция включена, участники видят более простой процесс:
Несколько важных деталей: коды действительны в течение 10 минут, истекают после 5 неудачных попыток и могут быть использованы только один раз.
Включение одноразовых кодов для входа в вашем сообществе
На данный момент это считается экспериментальным изменением! Прежде чем внедрять его более широко, мы будем рады вашим отзывам, которые помогут нам внести улучшения.
Чтобы включить эту функцию, перейдите на страницу Предстоящие изменения в разделе администратора (/admin/config/upcoming-changes) и найдите пункт Включить локальный вход по коду. Обновите поле Включено для…, чтобы активировать этот новый дизайн на вашем сайте:
Перед включением убедитесь, что оба параметра enable_local_logins и enable_local_logins_via_email также установлены в true, так как без них эту функцию невозможно включить. Если вы используете DiscourseConnect (enable_discourse_connect), эту функцию включить нельзя.
После включения изменения путь входа по коду появится автоматически.
Что вы думаете?
Слово за вами: нам очень хотелось бы услышать ваше мнение об этой новой функции. Что вам нравится и не нравится; что работает хорошо, а что можно улучшить?
Я только что попробовал это на своем сайте. Не уверен, что думают остальные, но для меня как пользователя менеджера паролей это выглядит как довольно серьезное ухудшение…
Этот новый процесс отменяет текущую стратегию «сгенерировать email, ввести имя пользователя, сгенерировать пароль, сохранить», к которой меня приучил мой менеджер паролей, и заставляет сначала вводить email перед всем остальным. У меня нет проблем с отправкой кода на email (и, честно говоря, я даже предпочитаю этот вариант, особенно если код указан в теме письма), но я категорически против удаления остальных полей для данных аккаунта. Если бы я был пользователем без технического бэкграунда, я бы тоже не стал вводить свой email в такое поле без пояснений, потому что это не распространенный дизайн. Было бы здорово, если бы эти поля вернули, прежде чем это станет постоянным решением.
Коды по электронной почте, также известные как «волшебные ссылки», — это нормально, но подталкивание пользователей к использованию ключей доступа значительно улучшает пользовательский опыт.
Для начала сайты, использующие волшебные ссылки, могут сделать ключи доступа опциональной функцией по выбору для тех клиентов, которые жаловались на то, как сегодня работают их волшебные ссылки. Чтобы убедиться, что это не вызовет никаких проблем, в качестве своего рода мягкого запуска они могут сделать эту функцию полностью опциональной.
Чуть позже, когда администраторы сайта убедятся, что ключи доступа действительно помогают решить проблемы с пользовательским опытом вокруг волшебных ссылок, они могут предлагать пользователям добавлять ключи доступа после входа в систему примерно раз в 90 дней или всякий раз, когда они входят в систему с помощью функции межприборного входа ключей доступа. Формулировка такого запроса для пользователей устройств Apple может быть примерно такой: Хотите избежать необходимости проверять электронную почту в следующий раз? Настройте ключ доступа, чтобы быстро и безопасно входить в систему с помощью Face ID или Touch ID.