mix phx.gen.auth

Создаёт логику аутентификации и связанные с ней представления для ресурса.

$ mix phx.gen.auth Accounts User users

Первый аргумент — модуль контекста, за которым следуют модуль схемы и её имя во множественном числе (используемое в качестве имени таблицы схемы). Приведённый выше пример создаст модуль контекста Accounts с двумя схемами: User и UserToken. Вы можете выбрать имена контекста и схемы по своему усмотрению. Например:

$ mix phx.gen.auth Identity Client clients

Создаст контекст Identity со схемами Client и ClientToken. Дополнительная информация и соображения по безопасности подробно описаны в руководстве mix phx.gen.auth.

LiveView и традиционные контроллеры и представления

Представления для аутентификации можно создать для использования с LiveView, передав параметр --live, или для использования с традиционными контроллерами и представлениями Phoenix, передав --no-live.

Если ни один из этих параметров не указан, будет показан запрос.

Рекомендуется использовать параметр --live, если вы планируете использовать LiveView в других частях приложения. При переходе между представлениями LiveView можно точно контролировать взаимодействие с пользователем и позволить ему переходить к представлениям аутентификации без обязательной отправки нового HTTP-запроса при каждом переходе (что привело бы к полной перезагрузке страницы).

Сочетание входа по волшебной ссылке и регистрации с паролем

mix phx.gen.auth создаёт аутентификацию на основе электронной почты, предполагающую, что пользователь, владеющий адресом электронной почты, контролирует учётную запись. Поэтому крайне важно аннулировать все токены доступа после того, как пользователь впервые подтвердит свою учётную запись. Для этого мы отзываем все токены при подтверждении.

Однако если вы разрешаете пользователям создавать учётную запись с паролем, необходимо также требовать, чтобы на момент подтверждения они вошли в систему. В противном случае система может быть уязвима к предварительному подбору учётных данных, поскольку возможна следующая атака:

1. Злоумышленник регистрирует новую учётную запись с адресом электронной почты своей цели, рассчитывая, что цель позднее создаст учётную запись.
2. При регистрации злоумышленник задаёт пароль.
3. Цель регистрирует учётную запись и видит, что её адрес электронной почты уже используется.
4. Цель входит в систему по волшебной ссылке, но не меняет существующий пароль.
5. Злоумышленник сохраняет доступ с помощью ранее заданного пароля.

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

Хеширование паролей

В Unix-системах по умолчанию используется механизм хеширования паролей bcrypt, а в Windows-системах — pbkdf2. Обе системы используют интерфейс Comeonin.

Механизм хеширования паролей можно переопределить с помощью параметра --hashing-lib. Поддерживаются следующие значения:

• bcrypt — bcrypt_elixir
• pbkdf2 — pbkdf2_elixir
• argon2 — argon2_elixir

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

Дополнительную информацию о выборе этих библиотек см. в проекте Comeonin.

Многократный запуск

Этот генератор можно запускать несколько раз. Обычно это полезно, если у вас есть отдельные ресурсы с разными сценариями аутентификации:

$ mix phx.gen.auth Store User users
$ mix phx.gen.auth Backoffice Admin admins

Обратите внимание: при многократном запуске phx.gen.auth будут созданы также несколько областей действия. Обычно достаточно одной области действия, поэтому, скорее всего, вам потребуется впоследствии настроить созданный код. Кроме того, сгенерированный код может содержать конфликты. Например, конвейер браузера по умолчанию попытается назначить обе области действия как :current_scope. Ключ назначения можно изменить с помощью параметра --assign-key.

Бинарные идентификаторы

Параметр --binary-id указывает генератору использовать binary_id в качестве первичных и внешних ключей в созданной миграции.

Параметры по умолчанию

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

config :your_app, :generators,
  binary_id: false,
  sample_binary_id: "11111111-1111-1111-1111-111111111111"

Эти параметры можно переопределить при каждом запуске, указав соответствующие флаги. Например, --no-binary-id позволит использовать обычные идентификаторы, несмотря на настройки по умолчанию.

Пользовательские имена таблиц

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

$ mix phx.gen.auth Accounts User users --table accounts_users

В результате созданные таблицы будут называться "accounts_users" и "accounts_users_tokens".

Пользовательское имя области действия

По умолчанию имя области действия совпадает с именем схемы. Чтобы изменить его, передайте параметр --scope. Например:

$ mix phx.gen.auth Accounts User users --scope app_user

Будет создана область действия с именем app_user вместо user. Подробнее об областях действия читайте в руководстве по областям действия.

Кроме того, ключ назначения области действия можно изменить, передав параметр --assign-key. Например:

$ mix phx.gen.auth Accounts User users --assign-key current_user_scope

Это полезно, если вы хотите запустить mix phx.gen.auth несколько раз в одном проекте. Однако часто разумнее повторно использовать ту же область действия, добавив дополнительные поля, вместо создания отдельных областей.