Компоненты авторизации и регистрации в CMS 1C-Bitrix / Хабр

Альтернативы

Если набраться смелости и залезть в исходный код системных компонентов (авторизации), то у вас резко пропадет любое желание работы с ними. Как очевидный альтернативный вариант на ум в первую очередь приходит создание собственных компонентов авторизации, регистрации и прочего. Благо API позволяет реализовать все тоже самое. Однако в этой альтернативе я вижу следующие жирные минусы:

— затраты на повторную реализацию логики (в одном лишь компоненте авторизации: проверочная капча, безопасная авторизация по ключу и авторизация через внешние сервисы),

— отказ от обновлений рассматриваемых системных компонентов, что особенно актуально с постепенным

Другой альтернативой можно считать компонент bitrix:main.register, обладающий широким спектром параметров. Однако для того чтобы именно этот компонент отображался и отрабатывал на целевой странице пользователя, программисту приходится идти на ухищрение: вставлять вызов этого компонента в шаблон системного компонента регистрации (bitrix:system.auth.register), что влечет за собой следующие недостатки:— один и тот же набор параметров компонента хранится как минимум в двух местах: в публичной части на странице авторизации и в шаблоне сайта,— при вызове bitrix:main.register через шаблон компонента bitrix:system.auth.register код последнего отрабатывает впустую.

Использование компонента авторизации внутри тела страницы

Иногда требуется встроить форму авторизации не вместо тела страницы, а внутрь тела страницы, например по адресу /about/index.php посреди контента. И тут возникает

нюанс

: оказывается системный компонент system.auth.authorize не делает совершенно ничего в отношении непосредственной авторизации, и поэтому сам ничего не знает о результате авторизации. Поэтому если мы подключим компонент без параметров, он будет корректно авторизовывать пользователей, но не будет отображать ошибки авторизации.

На самом деле механизм авторизации происходит где-то глубоко в недрах ядра, после чего ядро подключает компонент, передавая в него параметр «AUTH_RESULT» устанавливая значение из $APPLICATION->arAuthResult, что мы вынуждены повторять на своих страницах:

Похожее:  Личный кабинет Промсвязьбанка: вход в интернет-банк для физических и юридических лиц на официальном сайте

Корзина

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

Принцип работы

По умолчанию для авторизации и регистрации используются старые компоненты 1.0, использование которых нежелательно. Исправить это можно, отметив галку «Использовать Компоненты 2.0 для авторизации и регистрации» в настройках главного модуля или однократно выполнив код:

COption::SetOptionString('main', 'auth_comp2', 'Y');

Ознакомившись с описанием

мы видим, что на шаге 1.13 (еще до вывода header.php из шаблона сайта) идет проверка прав доступа уровня 1 и если она не пройдена, то выводится форма авторизации. Разберем это подробнее.

Под вызовом формы регистрации подразумеваются следующие действия:— порядок выполнения страницы продолжает выполнятся без изменений вплоть до пункта 3 «Тело страницы», включая выполнение header.php,— вместо «Тела страницы» в зависимости от переданных в $_REQUEST переменных подключается один из системных компонентов system.auth.* (конкретно system.auth.authorize если $_REQUEST пустой), в который передаются особые параметры (об этом ниже),— порядок выполнения страницы продолжает выполнятся без изменений, включая выполнение footer.php.

Проверка прав доступа «уровня 1» инициирует вызов формы авторизации в следующих случаях:— если глобальная константа NEED_AUTH определена и равна true,— если у пользователя (в том числе незарегистрированного) недостаточно прав для чтения запрошенного им файла.

Права на чтение файлов и разделов для разных групп пользователей формируются при редактировании оных административной панелью в служебных файлах .access.php. Каждый файл описывает уровни доступа к файлам и каталогам, расположенным на одном с ним уровне.

Прочие системные компоненты

Напомню что при инициации авторизации вместо «Тела страницы» компонент system.auth.authorize подключится ядром Битрикса только в случае, если пользователь явно не запросил какой-нибудь другой системный компонент из списка:

— ?forgot_password=yes подключит system.auth.forgotpasswd (отправка контрольного слова для смены пароля),

— ?change_password=yes подключит system.auth.changepasswd (смена пароля по контрольному слову),

— ?register=yes подключит system.auth.registration (регистрация),

— ?confirm_registration=yes подключит system.auth.confirmation (подтверждение регистрации).

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

Расширение функционала регистрации

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

Создание собственных шаблонов

Для того чтобы настроить внешний вид системных форм авторизации, регистрации, запроса смены пароля и смены пароля по контрольной строке, вам следует скопировать существующие шаблоны этих компонентов (/bitrix/components/bitrix/system.auth.*/templates/.default) в шаблон сайта (/bitrix/templates//components/bitrix/system.auth.*/.default), после чего работать с ними.

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

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

В заключение

Не секрет что платформа Битрикс далека от идеала. Каждый раз когда я встречаю подобные вещи, искажающие мой покерфейс, я сперва называю из

странными

, затем пытаюсь разобраться и понять

почему же было сделано именно так

и в большинстве случаев нахожу

приемлемый

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *