# Разделить вход/регистрацию по электронной почте без пароля и включение локального входа
**URL:** https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556
**Category:** Feature
**Tags:** login
**Created:** [26.Апрель.2026 13:33:56 UTC](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556 "2026-04-26T13:33:56Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [26.Апрель.2026 13:33:56 UTC](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556/1 "2026-04-26T13:33:56Z")
Я хотел бы запросить поддержку **истинного локального процесса без пароля** в Discourse, без необходимости полагаться на внешнего провайдера идентификации, такого как Microsoft, Google и т. д.
На данный момент, насколько я могу судить, в Discourse уже есть отдельные элементы этого функционала, но отсутствует необходимая комбинация настроек.
### Что существует сегодня
В Discourse уже есть:
- локальные учетные записи
- ссылки для входа по электронной почте / поведение входа без пароля через настройку `enable local logins via email`
- процессы приглашения, где пароль может быть отложен
- автоматическое создание учетных записей при внешней аутентификации через OIDC / OAuth / SAML / [DiscourseConnect](https://meta.discourse.org/t/13045?silent=true)
Однако недостающим элементом является то, что **вход по электронной почте для локальных аккаунтов все еще привязан к локальным входам в целом**. Это означает, что я не могу четко задать:
- **разрешить вход по магической ссылке для локальных аккаунтов по email**
- **разрешить регистрацию/онбординг по магической ссылке для локальных аккаунтов по email**
- **запретить вход с использованием локального пароля**
Именно эту комбинацию я хочу получить.
## Сценарий использования
Я хочу, чтобы Discourse нативно поддерживал следующую модель:
1. Пользователь заходит на сайт.
2. Пользователь вводит адрес электронной почты.
3. Discourse отправляет ему одноразовую ссылку для входа с коротким сроком действия.
4. Если у пользователя еще нет учетной записи, Discourse создает её.
5. Пользователь входит в систему.
6. В дальнейшем вход может осуществляться тем же способом.
7. Локальный пароль не требуется, если администратор явно не захочет его разрешить.
Другими словами:
> локальная учетная запись
> локальная проверка владения email
> локальный пароль не требуется
## Почему это важно
В данный момент, если кто-то хочет получить опыт работы без пароля, самым чистым обходным путем кажется использование внешнего провайдера идентификации. Но это не идеально для каждого сайта.
Некоторые причины:
- не каждое сообщество хочет зависеть от Microsoft / Google / Auth0 и т. д.
- некоторые сообщества хотят более простой и сохраняющий конфиденциальность локальный процесс аутентификации
- некоторые сообщества хотят снизить трение, связанное с паролями, не передавая управление идентификацией на аутсорсинг
- некоторые администраторы хотят поддержать пользователей, которые плохо справляются с паролями, но отлично работают со ссылками на почту
В Discourse уже есть прецедент входа без пароля через ссылки на email, поэтому это ощущается скорее как отсутствующий режим работы продукта, чем как совершенно новая концепция.
## Что я прошу
Я думаю, что эту проблему можно решить, **разделив** эти понятия:
### Текущее поведение
- `enable local logins`
- `enable local logins via email`
### Запрашиваемое поведение
Позвольте администраторам независимо управлять следующими параметрами:
- **разрешить вход по локальному паролю**
- **разрешить вход по локальной ссылке на email**
- **разрешить регистрацию по локальному паролю**
- **разрешить регистрацию/создание аккаунта по локальной ссылке на email**
## Пример желаемой модели настроек
Что-то вроде:
- `enable local password logins`
- `enable local email logins`
- `enable local password signup`
- `enable local email signup`
- возможно, `local email signup creates account automatically`
- возможно, `local email signup requires staff approval`
- возможно, `local email login link expiry minutes`
Не обязательно именно эти названия настроек, важен сам концепт.
## Желаемый UX
### Вход в систему
Пользователь должен иметь возможность выбрать:
- продолжить с паролем
- или **отправить мне ссылку для входа на email**
Если вход по паролю отключен, отображается только вариант со ссылкой на email.
### Регистрация
Пользователь должен иметь возможность выбрать:
- создать аккаунт с паролем
- или **создать аккаунт через ссылку на email**
Если регистрация с паролем отключена, сайт должен автоматически использовать регистрацию по ссылке на email.
## Почему приглашений недостаточно
Приглашения помогают в онбординге, но они не то же самое, что настоящий локальный режим аутентификации без пароля.
Насколько я понимаю:
- приглашения в основном предназначены для принятия / активации
- они не являются постоянными учетными данными пользователя для входа
- после истечения срока сессии пользователям все равно нужен обычный путь входа
Таким образом, приглашения связаны с этим, но они не решают проблему полностью.
## Почему внешней аутентификации недостаточно
Да, OIDC / OAuth / SAML могут обеспечить опыт работы без пароля или на основе одноразовых кодов (OTP), и настройка `auth skip create confirm` во многом помогает в этом.
Но это означает, что сайт теперь зависит от стороннего провайдера идентификации.
Для некоторых сообществ это приемлемо. Для других это лишняя сложность и нежелательная зависимость.
## Вопросы безопасности
Я понимаю, что аутентификация по ссылке на email имеет свои последствия для безопасности, но в Discourse уже есть подобные паттерны, такие как:
- сброс пароля по email
- вход по ссылке на email
- принятие приглашения по email
Таким образом, это не внедрение идеи подтверждения контроля над email с нуля.
Разумные меры предосторожности могут включать:
- ссылки с коротким сроком действия
- агрессивные ограничения частоты запросов (rate limits)
- одноразовые токены
- опциональная двухфакторная аутентификация (2FA) после входа по ссылке
- опциональная задержка перед изменением email или пароля после входа по магической ссылке
- видимость для администратора / логи входа по ссылкам на email
## Кратко
Я прошу о **полноценном локальном режиме работы без пароля** в Discourse, где:
- пользователи аутентифицируются, подтверждая контроль над своим email
- Discourse может создавать локальные учетные записи в рамках этого процесса
- администраторы могут полностью отключить вход по локальному паролю
- это работает без необходимости использования Microsoft / Google или другого провайдера SSO
Я считаю, что это будет очень полезной функцией для сообществ, которые хотят минимизировать трение при онбординге, не передавая управление идентификацией на аутсорсинг.
---
### Author:  [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)
#### Post date: [26.Апрель.2026 14:05:31 UTC](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556/2 "2026-04-26T14:05:31Z")
> [@Ethsim2](#):
>
> Вход по волшебной ссылке через локальную почту
Эта функция уже доступна. И она работает отлично.
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [26.Апрель.2026 14:07:05 UTC](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556/3 "2026-04-26T14:07:05Z")
Как можно настроить страницу регистрации так, чтобы было понятно: поле пароля заполнять не обязательно? Также как с помощью CSS скрыть поля «Электронная почта» и «Пароль» на странице `/login`?
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [26.Апрель.2026 14:08:13 UTC](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556/4 "2026-04-26T14:08:13Z")
> [@Ethsim2](#):
>
> - некоторые администраторы хотят поддержать пользователей, которые плохо справляются с паролями, но отлично умеют работать со ссылками в письмах
скажите им использовать менеджер паролей.
---
### Author:  [@Bruce5051](https://meta.discourse.org/u/Bruce5051)
#### Post date: [26.Апрель.2026 20:47:27 UTC](https://meta.discourse.org/t/decouple-passwordless-email-login-signup-from-enable-local-logins/401556/5 "2026-04-26T20:47:27Z")
> [@Lilly](#):
>
> менеджер паролей
Рекомендую 1Password; он также будет сохранять PassKeys.