Как устроена авторизация и регистрация в CMS 1C-Bitrix

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

Под вызовом формы регистрации подразумеваются следующие действия:

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

Проверка прав доступа инициирует вызов формы авторизации в следующих случаях:

Если глобальная константа NEED_AUTH определена и равна true
Если у пользователя в том числе незарегистрированного недостаточно прав для чтения запрошенного им файла

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

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

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

Использовать же глобальную константу NEED_AUTH рекомендую только в специфических случаях, одним из которых является непосредственно страница авторизации в стандартной поставке демо-сайта по адресу /auth/index.php:

/auth/index.php<?
define("NEED_AUTH", true);
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
IncludeModuleLangFile($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/intranet/public/about/auth/index.php");
// ... 
$APPLICATION->SetTitle(GetMessage("AUTH_TITLE"));
?>
<p><?=GetMessage("AUTH_SUCCESS")?></p>
<p><a href="<?=SITE_DIR?>"><?=GetMessage("AUTH_BACK")?></a></p>
<?require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>

Этот скрипт передает управление ядру Битрикса, определив перед этим константу NEED_AUTH. Битрикс, в случае если пользователь не авторизован, подключает шапку + системный компонент авторизации + подвал и умирает, не позволяя скрипту выполняться дальше второй строчки. В случае же если пользователь авторизован — ему выводится приветственное сообщение и ссылка на корень сайта.

При инициации авторизации вместо страницы компонент 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 (подтверждение регистрации)

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

Подключение компонентов

В Битрикс есть два способо подключения компонентов связаных с доступом:

Физически на странице
Через админку

Физически на странице

Иногда требуется встроить форму авторизации не вместо тела страницы, а внутрь тела страницы, например по адресу /about/index.php посреди контента. И тут возникает нюанс, оказывается системный компонент system.auth.authorize не делает совершенно ничего в отношении непосредственной авторизации, поэтому сам ничего не знает о результате авторизации. Если мы подключим компонент без параметров, он будет корректно авторизовывать пользователей, но не будет отображать ошибки авторизации. На самом деле механизм авторизации происходит где-то глубоко в недрах ядра, после чего ядро подключает компонент, передавая в него параметр AUTH_RESULT устанавливая значение из $APPLICATION->arAuthResult, что мы вынуждены повторять на своих страницах:

<? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php"); ?>
...
<? if (!$USER->IsAuthorized()): ?>
    <? $APPLICATION->IncludeComponent(
        'bitrix:system.auth.authorize', 
        '', 
        array('AUTH_RESULT' => $APPLICATION->arAuthResult)
    ); ?>
<? endif; ?>
...
<? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/footer.php"); ?>

Если же необходимость в авторизации возникает во время выполнения компонента, следует вызвать форму авторизации методом CMain::AuthForm(), что позволит пользователю авторизоваться не только не покидая целевой страницы, но и сохранить все параметры в URL:

$APPLICATION->AuthForm(array(
	"MESSAGE" => "Для работы с ... требуется авторизация.",
	"TYPE" => "OK",
));

Через админку

Все настройки в админке находятся по поти Настройки -> Настройки продукта -> Настройки модулей -> Главный модуль вкладка Авторизация:

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

В этом случае в момент когда потребуется авторизация подключится компонент без физического вызова на странице.