Немного теории
Пользователи
Сложные современные сайты (маркетплейсы, личные кабинеты, сервисы) предполагают авторизацию пользователей. Ранее мы рассмотрели добавление пользователей путем самостоятельной регистрации через публичную часть и создание пользователей через форму в разделе администратора.
При переносе базы пользователей из другой системы в «1С-Битрикс: Управление сайтом» оба этих способа будут неудобными. Поэтому в системе есть возможность массового импорта списка пользователей через CSV-файл.
Для импорта обязательно наличие следующих столбцов:
- NAME (Имя)
- LAST_NAME (Фамилия)
Остальные поля система может «додумать», если они не будут указаны:
- PASSWORD (пароль) генерируется случайным образом
- EMAIL (E-mail) составляется по настройкам сайта
- LOGIN (Логин) составляется из имени и фамилии
Если вы хотите, чтобы пользователи проходили авторизацию по почте, а не по логину, то перед импортом CSV нужно в любом редакторе табличных файлов скопировать колонку EMAIL и переименовать ее в LOGIN. Тогда в этих полях пользователей будут одинаковые значения.
Если в настройках Главного модуля установлены настройки «Номер телефона является обязательным», «Email является обязательным полем», то эти поля также должны указываться в CSV-файле
Сразу после импорта пользователи могут пройти авторизацию и попасть на сайт. Если пароль был сгенерирован, то они должны начать свою работу со страницы «Я забыл свой пароль», так как способа узнать его нет — в БД пароль хранится в виде хэш-суммы.
Механизм восстановления пароля
Для хорошего разработчика важно понимать процедуру восстановления пароля в «1С-Битрикс: Управление сайтом». Главное — понять что пароль не «восстанавливается», а создается новый.
На первом шаге этой процедуры пользователь должен указать свой E-mail. Если такая почта зарегистрирована в системе, на нее будет выслано служебное письмо с уникальной ссылкой на страницу создания нового пароля. Уникальной ссылку делает зашитый в нее сгенерированный ключ специально созданный для этого пользователя.
Почему бы сразу не генерировать новый пароль? Ответ простой — тогда у злоумышленника или просто невнимательного человека будет способ обновлять пароли любых пользователей. Поэтому такая важная процедура выполняется исключительно в 2 этапа.
Перейдя по ссылке, пользователь может указать новый пароль. Если ссылка была корректной (с корректным ключом), пароль будет обновлен и пользователю придет новое письмо об успешной смене пароля. А уникальной ссылкой для смены пароля больше никто не сможет уже воспользоваться.
Группы пользователей
Основной инструмент для объединения пользователей в системе — группы пользователей. Выделение групп — небольшой, но важный этап проектирования и разработки сайта.
Пользователь может быть добавлен в произвольное количество групп. В интерфейсе администратора сайта пользователей можно фильтровать по группам или массово перемещать между ними.
Изменение групп пользователя происходит сразу же. Изменение списка групп, как и изменение прав для этой группы, не требует перезагрузки или повторной авторизации пользователя.
Помимо логической группировки пользователей, на основе системы групп в «1С-Битрикс: Управление сайтом» построена система прав. Функциональные ограничения привязываются именно к группам: доступ к инфоблокам, файлам сайта, профилю, настройкам модулей и прочим системным функциям.
Даже если активная работа в административном разделе не предполагается, названия групп должны быть очевидными. В реальных проектах используют два способа именования:
- От терминологии заказчика. Если бизнес использует слова «дилер», «кладовщик», «первостольник» — это отличный вариант названия групп. Тем более, что в таких случаях бизнес сможет четко объяснить, какими полномочиями эти пользователи отличаются.
- От прав доступа. Особенно это полезно при развитии уже существующего проекта при тестировании новых гипотез. Примеры таких групп: «Пользователи с правом покупать по оптовым ценам», «Пользователи, которые могут оставлять отзывы».
Компоненты для работы с пользователями
В системе есть 4 основных действия с авторизационными данными пользователя:
- Самостоятельная регистрация нового пользователя (с подшагами — инициализация регистрации, подтверждение регистрации)
- Авторизация
- Запрос ссылки на смену пароля
- Смена пароля
Для каждой операции существует как минимум 2 подходящих компонента, system.auth.* (системный) и main.auth.* (публичный). Эти компоненты со ссылками на документацию приведены в таблице ниже.
| Компоненты | Назначение |
|---|---|
| main.auth.form
system.auth.authorize, system.auth.form |
Форма авторизации |
| main.auth.changepasswd
system.auth.changepasswd |
Форма смены пароля |
| main.auth.forgotpasswd,
system.auth.forgotpasswd |
Форма запроса ссылки смены пароля |
| system.auth.initialize | Системный компонент инициализации регистрации |
| main.register,
system.auth.registration |
Форма регистрации |
| system.auth.confirmation | Страница подтверждения регистрации |
Системные компоненты умеет подключать сам фреймворк, если видит в этом необходимость. Если сайт закрыть от анонимных пользователей (NEED_AUTH или вызов CMain::AuthForm), то при посещении любой страницы, авторизованный пользователь увидит обычное содержимое страницы, а неавторизованный — форму входа, отрисованную компонентом system.auth.authorize. При этом header.php и footer.php шаблона сайта выполнятся в обоих случаях.
Остальные компоненты будут подключаться при следующих условиях:
| Компоненты | Назначение |
|---|---|
| system.auth.forgotpasswd |
|
| system.auth.changepasswd |
|
| system.auth.registration |
|
| system.auth.confirmation |
|
Вы можете изменить шаблон нужного вам компонента, чтобы он соответствовал дизайну сайта. По-умолчанию фреймворк подключает во всех случаях шаблон компонента “.default”. В настройках главного модуля, во вкладке “Авторизация” можно указать желаемое название шаблона в поле “Шаблон системных компонентов авторизации (system.auth.*)”
Системные компоненты авторизации написаны в процедурном стиле, в отличии от main- компонентов авторизации, которые написаны в ООП парадигме. Мы не сможем расширить системный компонент авторизации без его копирования.
Системные компоненты сами не авторизуют и не регистрируют пользователя, только выводят html формы. Логика регистрации/авторизации происходит в прологе, в ядре фреймворка. Результат этой обработки сохраняется в поле $APPLICATION->arAuthResult. Эти данные передаются в системные компоненты как параметр $arParams[“AUTH_RESULT”]. Это приводит к неочевидным последствиям (см. далее).
Компоненты “main” в этом плане отличаются. Они не только выводят форму, они сами ее и обрабатывают.
Создание раздела с авторизацией
Таким образом, можно назвать 4 способа создания страниц авторизации:
- Описанный в курсе “Администратор. Базовый” с помощью system.auth.* компонентов
- Аналогичный способ с помощью main.* компонентов
- Объявление константы NEED_AUTH
- Вызов CMain::AuthForm
Самый наглядный способ — через компоненты. Именно так работают все прочие страницы и разделы фреймворка. Их можно разместить на любой странице, задав желаемый URL, детально настроить или даже переопределить. Но нужно будет самостоятельно создать все разделы и папки, вызвать компоненты и не забыть поправить почтовые шаблоны, в которых будет ссылка на страницу восстановления пароля и регистрацию.
Важная особенность компонентов system.auth.* — их нельзя размещать на одной и той же странице. У всех таких компонентов сообщение об ошибке или успехе хранится в одной и той же переменной. Поэтому в случае ошибки или успеха одной формы, все остальные покажут такой же результат.
Константа или вызов метода легко не заметить при работе с сайтом. Также при выборе последних 2-ух вариантов у разработчика не будет возможности повлиять на формируемый адрес страницы. Но это самый быстрый способ создать раздел с авторизацией.
Практика
В этом видео рассмотрим работу с пользователями и авторизацией.
Пользователи и авторизация
11 мин