Как настроить регистрацию битрикс

Настраиваемая регистрация

Компонент позволяет настроить форму регистрации на сайте.

Описание main.register

Компонент позволяет:

• установить, какие параметры будут предложены пользователю для заполнения, какие из них будут обязательны для заполнения;
• настроить ЧПУ;
• установить настройки кеширования;
• регулировать дальнейшие переходы пользователя по страницам сайта после регистрации: по ссылке в параметре backurl или на страницу окончания регистрации и т.д.

Компонент стандартный и входит в дистрибутив модуля.

В визуальном редакторе компонент расположен по пути: Служебные > Пользователь > Настраиваемая регистрация.

Параметры

Поле	Параметр	Описание
Основные параметры
Поля, которые показывать в форме	SHOW_FIELDS	Указываются поля, которые будут выведены в дополнение к стандартному набору в форме регистрации. Стандартными полями, обязательными для заполнения, являются: Логин; Пароль; Подтверждение пароля; Адрес E-mail. Дополнительными полями являются: имя, фамилия, отчество, профессия и другие личные данные.
Поля, обязательные для заполнения	REQUIRED_FIELDS	Указываются обязательные для заполнения поля. Список допустимых значений такой же, что и в предыдущем пункте.
Дополнительные настройки
Автоматически авторизовать пользователей	AUTH	[Y|N] При отмеченной опции после регистрации пользователь будет автоматически авторизован на сайте. В противном случае после регистрации пользователю будет предоставлена к заполнению форма авторизации.
Отправлять пользователя по обратной ссылке, если она есть	USE_BACKURL	[Y|N] При отмеченной опции пользователь будет отправлен по обратной ссылке, если она есть. При наличии в адресной строке параметра backurl пользователь будет перенаправлен по указанной в этом параметре ссылке после заполнения формы регистрации.
Страница окончания регистрации	SUCCESS_PAGE	Указывается адрес страницы сайта, которая будет финальной страницей процедуры регистрации, и пользователь будет перенаправлен на нее в случае успешной регистрации. Если пользователь зарегистрирован и авторизован, то при переходе на страницу регистрации он попадет на страницу окончания регистрации. Примечание: один из параметров (USE_BACKURL или SUCCESS_PAGE) лучше заполнить. Если отмечены оба параметра, то пользователь будет переведен по обратной ссылке.
Устанавливать заголовок страницы	SET_TITLE	[Y|N] При отмеченной опции в качестве заголовка страницы будет установлено Регистрация нового пользователя.
Показывать доп. свойства	USER_PROPERTY	Указываются дополнительные пользовательские свойства, если они заданы.
Название блока пользовательских свойств	USER_PROPERTY_NAME	Указывается название блока пользовательских свойств.

Пример вызова

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

Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

Также Пользовательские комментарии не являются местом для обсуждения функционала. По подобным вопросам обращайтесь на форумы.

Задача : Необходимо передалать регистрационную форму так, чтобы там появились обязательные поля ФИО, телефон и т.д.

1. Скопировать стандартный шаблон компонента bitrix.system.auth.registration в папку шаблона сайта
2. В этом шаблоне разместить примерно следующий код:

3. Настроить параметры: «SHOW_FIELDS» и «REQUIRED_FIELDS».

Источник

Битрикс. Регистрация и авторизация. Часть 2 из 3

Возможности системного компонента регистрации довольно скромные: нет возможности добавить свои поля, сделать их обязательными для заполнения. Для реализации таких возможностей есть компонент «Настраиваемая регистрация», который позволяет настроить и разместить на сайте свою форму регистрации. В визуальном редакторе компонент расположен по пути: «Служебные • Пользователь • Настраиваемая регистрация».

Пример вызова компонента

Создадим страницу /auth/register.php , разместим на ней вызов компонента «Настраиваемая регистрация». В настройках компонента выберем поля, которые надо показывать:

• [EMAIL] E-mail
• [NAME] Имя
• [LAST_NAME] Фамилия
• [PERSONAL_PHONE] Телефон
• [WORK_COMPANY] Наименование компании
• [WORK_PHONE] Телефон (рабочий)

И укажем поля, обязательные для заполнения:

• [EMAIL] E-mail
• [NAME] Имя
• [LAST_NAME] Фамилия
• [PERSONAL_PHONE] Телефон

После этого страница /auth/register.php содержит следующий код:

И имеет такой вид:

Теперь нам надо кастомизировать форму регистрации под наш дизайн. Для этого копируем шаблон компонента:

• откуда: bitrix/components/bitrix/main.register/templates/.default
• куда: local/templates/.default/components/bitrix/main.register/.default

После внесения изменений получилось так:

И вот что получилось в итоге:

Тут есть еще один важный момент. Что будет, если на эту страницу попадает авторизованный пользователь? Ему показывается малоинформативное сообщение, что он зарегистрирован и авторизован.

Есть смысл перенаправить его на страницу личного кабинета или на страницу профиля:

Пользовательские поля

Хотя Битрикс предлагает большой набор предопределенных полей, их все-таки может не хватить. Тогда остается только создавать свои поля. Это можно сделать в панели управления: «Настройки • Настройки продукта • Пользовательские поля»:

Я добавил поле «Мое поле», тип «Строка», в настройках компонента указал, что это поле надо показывать:

Теперь форма регистрации имеет вид:

Порядок полей

Для настройки порядка следования полей в форме, создадим файл local/templates/.default/components/bitrix/main.register/.default/result_modifier.php :

В результате чего форма примет вид:

Авторизация по E-mail

Давайте уберем поле LOGIN , как отживший свое пережиток прошлого. Без этого поля регистрацию пользователь не пройдет, поэтому будем создавать LOGIN из EMAIL . Добавляем в init.php следующий код:

Чтобы форма регистрации не выдавала ошибок «Не заполнено обязательное поле логин», внесем изменение в шаблон компонента:

Еще раз изменим порядок следования полей в форме и сделаем поле LOGIN первым, чтобы можно было его скрыть, обратившись с помощью :first-of-type :

Теперь скроем поле LOGIN :

Но есть еще одна проблема — у нас теперь две формы регистрации с разным составом полей:

• первая формируется системным компонентом system.auth.registration и доступна по адресу /auth/?register=yes
• вторая формируется компонентом bitrix:main.register и доступна по адресу /auth/register.php

Давайте это исправим. Удалим весь код из шаблона компонента system.auth.registration , и поместим в него вызов компонента bitrix:main.register из файла /auth/register.php :

А файл /auth/register.php просто удалим. Можно еще удалить лишний код из шаблона компонента bitrix:main.register , который никогда не будет выполнен. Системный компонент system.auth.registration вызывается где-то глубоко в недрах Битрикс только в том случае, если пользователь не авторизован. И еще одна проверка в шаблоне «Пользователь авторизован?» просто не нужна.

Не забываем изменить другие системные компоненты:

Есть еще один момент, о котором есть смысл упомянуть. Если при изменении пароля не заполнить поле «E-mail», появляется сообщение об ошибке «Логин должен быть не менее 3 символов». Где это изменить, я не нашел, видимо где-то в недрах ядра Битрикс. Поэтому небольшой хак:

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Событие OnBeforeUserRegister примечательно тем, что не вызывается при обычном добавлении пользователя, будь то вызов API или ручное добавление в административной части, что позволяет изменить логику именно регистрации пользователя-гостя, накладывая дополнительные ограничения на поля или обрабатывая дополнительные поля, например контроль за цифрами в телефоне, контроль за наличием данных в имени и фамилии.

Задача обработчика события — скорректировать входящий массив данных $arArgs или объявить об ошибке методом CMain::ThrowException(), вернув false вместо массива данных. К сожалению добиться того чтобы интересующие нас поля передавались через $arArgs невозможно, поэтому приходится анализировать $_REQUEST. Листинг можно улучшить, сгруппировав найденные ошибки, но к сожалению даже если обработчик успешно отработает, в дальнейшем в процессе регистрации в ядре могут возникнуть другие ошибки, влиять на которые мы не можем. Пользователь не доволен, получая разные ошибки в процессе регистрации. Программист ищет альтернативы.

Событие OnAfterUserAdd вызывается не только после успешной самостоятельной регистрации пользователя, но и при вызовах API или добавлении пользователя в административной части, но передаваемый в обработчики этого события массив данных ни на что не влияет кроме самих обработчиков, поэтому генерировать исключения здесь практически бесполезно, но зато вместо этого можно выполнить некоторую общую для всех новых пользователей логику, как то: добавить пользователя в лист рассылки, создать для него бюджет в интернет-магазине или присвоить какое-либо пользовательское свойство.

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

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

Источник