В версиях Битрикс начиная с 24.0 функционал единой авторизации интегрирован в ядро системы и управляется через модуль main.auth. Для отключения единого входа потребуется корректная настройка прав пользователей и проверка всех активных сервисов, использующих SSO-токены.
Первый шаг – переход в Настройки > Пользователи > Параметры авторизации. Здесь необходимо деактивировать опцию «Единая авторизация для всех доменов» и сохранить изменения. После этого система перестанет автоматически синхронизировать учетные записи между порталами и внешними сервисами.
Второй шаг – проверка скриптов и компонентов, подключающих oauth или sso. Необходимо заменить автоматические вызовы авторизации на стандартные формы входа /auth.php, а также убедиться, что все пользовательские группы имеют корректные права для локального входа.
Третий шаг – тестирование. Создайте несколько учетных записей с разными ролями и выполните вход на каждом домене отдельно. Убедитесь, что сессии не пересекаются и данные пользователей корректно сохраняются в таблицах b_user и b_user_session.
Отключение единой авторизации требует последовательного контроля каждого сервиса, задействованного в портале. Любой пропущенный компонент SSO может привести к ошибкам входа или нарушению прав доступа, поэтому рекомендуется фиксировать все изменения в журнале администрирования.
Отказ от единой авторизации в Битрикс: пошаговое руководство
1. Войдите в административную панель Битрикс с правами администратора.
2. Перейдите в раздел «Настройки» → «Инструменты» → «Единая авторизация». Здесь отображаются все активные подключения к единой системе авторизации.
3. Снимите флажки с активных интеграций: LDAP, OAuth, SSO, социальные сети. Это отключит автоматическую синхронизацию пользователей.
4. Перейдите в «Пользователи» → «Список пользователей» и убедитесь, что локальные аккаунты имеют уникальные пароли. При необходимости выполните массовую генерацию паролей через стандартный скрипт Битрикс.
5. В файле /bitrix/.settings.php удалите или закомментируйте блоки, отвечающие за единую авторизацию. Обратите внимание на массивы auth_services и oauth_clients.
6. Очистите кэш сайта через «Настройки» → «Инструменты» → «Очистка кеша» и убедитесь, что изменения вступили в силу.
7. Проверьте работу локальной авторизации: создайте тестового пользователя, выполните вход через стандартную форму и убедитесь, что доступ предоставляется корректно.
8. При необходимости настройте уведомления о смене пароля или сбросе доступа для пользователей, чтобы они могли самостоятельно восстанавливать учетные записи без единой авторизации.
9. Для интеграций с внешними системами проверьте отдельные модули, например CRM и интернет-магазин, чтобы отключение единой авторизации не нарушило работу API.
10. Документируйте все изменения в конфигурации, чтобы при необходимости можно было восстановить подключение единой авторизации без потери данных.
Проверка текущей конфигурации единой авторизации
Для начала необходимо определить, активирован ли модуль единой авторизации в системе Битрикс. Это делается через административную панель: Настройки → Настройки продукта → Модули. В списке модулей ищите «Единая авторизация». Если статус «Установлен», переходите к анализу настроек.
Следующий шаг – проверка привязки к внешним системам. В административной панели откройте Настройки → Настройки продукта → Единая авторизация → Настройка подключения. Здесь отображаются подключенные домены и внешние сервисы. Обратите внимание на поля:
| Параметр | Описание | Рекомендация |
|---|---|---|
| Домен | Адрес сайта, на котором активна единая авторизация | Сравните с основным доменом проекта; несовпадение требует корректировки |
| Внешние сервисы | Список подключенных SSO-провайдеров | Проверьте актуальность токенов и URL обратного вызова |
| Тип авторизации | Протокол (OAuth, OpenID, SAML) | Запишите для дальнейшей деактивации и настройки локальной авторизации |
Дополнительно проверяется структура пользовательских групп и их соответствие единой авторизации. В Настройки → Пользователи → Группы убедитесь, что права на вход через SSO не конфликтуют с локальными группами.
Для полной диагностики используйте файл /bitrix/.settings.php. В нём ищите блоки:
| Блок | Что содержит | Проверка |
|---|---|---|
| auth | Настройки единой авторизации, идентификаторы приложений, ключи | Сравните с актуальными данными внешних сервисов, отметьте устаревшие |
| domains | Список доменов, разрешённых для SSO | Удалите лишние домены перед отключением |
Финальная проверка – тестирование входа. Создайте временного пользователя и попытайтесь авторизоваться через SSO и локальный логин. Фиксируйте все ошибки, чтобы на этапе отключения не потерять доступ к системе.
Выключение модуля единой авторизации в админке
Для отключения единой авторизации в Битрикс перейдите в административную панель по адресу /bitrix/admin/. В меню слева выберите раздел Настройки → Модули.
В списке установленных модулей найдите Единая авторизация (идентификатор модуля socialservices). Нажмите на название модуля для перехода к его настройкам.
На странице настроек модуля отключите все активные интеграции с внешними сервисами, включая OAuth, LDAP и соцсети. Убедитесь, что сняты галочки с опций Разрешить авторизацию через внешние сервисы и Использовать единую сессию.
После отключения интеграций прокрутите страницу вниз и нажмите кнопку Сохранить. Система сохранит изменения и перестанет использовать модуль единой авторизации.
Для окончательного удаления модуля вернитесь к списку модулей, выделите Единая авторизация и нажмите Удалить. Подтвердите действие, чтобы полностью исключить модуль из системы. Перед удалением рекомендуется создать резервную копию базы данных.
После удаления убедитесь, что локальная авторизация пользователей функционирует корректно. Проверьте вход под различными аккаунтами и убедитесь, что интеграции с внешними сервисами больше не активны.
Настройка отдельных учетных записей для пользователей
Для организации отдельных учетных записей в Битрикс откройте раздел «Пользователи» в административной панели. Нажмите «Добавить пользователя» и заполните обязательные поля: логин, e-mail и пароль. Пароль рекомендуется генерировать с использованием встроенного генератора длиной не менее 12 символов, включая цифры, прописные и строчные буквы, а также специальные символы.
После создания учетной записи настройте группы доступа. Перейдите в «Настройки пользователей» → «Группы пользователей» и создайте отдельную группу для нового пользователя или выберите существующую с минимально необходимыми правами. Назначение группы важно для ограничения доступа к административным разделам и критичным данным.
Включите двухфакторную аутентификацию для учетной записи через «Настройки безопасности» → «Двухфакторная аутентификация». Выберите метод подтверждения: SMS, e-mail или приложение-генератор кода. Это повысит защиту данных и уменьшит риск несанкционированного доступа при отказе от единой авторизации.
Для пользователей, которым необходим доступ к конкретным модулям, настройте права через «Права доступа к модулям». Укажите точные действия, которые разрешены: просмотр, редактирование или администрирование. Рекомендуется проверять права после настройки, используя тестовую учетную запись, чтобы исключить лишние привилегии.
Если требуется ограничить вход по IP-адресам, активируйте «Белые IP» в настройках безопасности. Добавьте диапазоны адресов сотрудников или филиалов. Это предотвратит вход с посторонних сетей, сохраняя работу отдельных учетных записей в защищенном режиме.
Регулярно проверяйте активность пользователей в разделе «Журнал посещений». Это позволит выявлять необычные входы и корректировать права доступа при необходимости. Для удобства можно настроить уведомления на e-mail при подозрительных действиях.
После завершения настройки убедитесь, что каждая учетная запись функционирует независимо, а пользователь может выполнять только необходимые действия без доступа к глобальным административным функциям.
Изменение логики входа через стандартные компоненты
Для изменения логики входа в Битрикс через стандартные компоненты необходимо работать с компонентом bitrix:system.auth.form. Первым шагом следует скопировать стандартный шаблон компонента в папку /local/templates/ваш_шаблон/components/bitrix/system.auth.form/. Это позволит вносить изменения без модификации ядра.
Внутри шаблона можно изменить обработку формы. Для этого нужно модифицировать файл template.php, добавив проверку конкретных условий входа, например, проверку отдельного поля UF_CUSTOM_FIELD в профиле пользователя:
if ($USER->GetParam('UF_CUSTOM_FIELD') !== 'allowed') { $APPLICATION->ThrowException('Доступ запрещен'); }
Если требуется использовать альтернативную аутентификацию, например через внешний LDAP или API, нужно подключить кастомный обработчик события OnBeforeUserAuthorize в /local/php_interface/init.php:
AddEventHandler("main", "OnBeforeUserAuthorize", "CustomAuthHandler");
Функция CustomAuthHandler должна возвращать false для запрещенных попыток входа и выполнять авторизацию через $USER->Authorize($ID); для разрешенных пользователей.
Для контроля редиректов после входа измените параметр AUTH_URL в шаблоне, указывая путь на отдельную страницу или отдельный раздел сайта:
$arResult["AUTH_URL"] = "/personal/dashboard.php";
Важно тестировать все изменения на отдельной тестовой копии сайта. Любые ошибки в логике авторизации могут привести к блокировке пользователей или обходу стандартных ограничений безопасности.
Обновление страниц авторизации и регистрации
После отключения единой авторизации необходимо пересмотреть шаблоны страниц auth.php и registration.php в шаблоне вашего сайта. Начните с проверки форм ввода: поле LOGIN должно иметь уникальный идентификатор, чтобы не конфликтовать с другими формами на сайте. Аналогично, поле PASSWORD и подтверждение пароля должны использовать name и id соответствующие стандартам Битрикс.
Следующий шаг – обновление обработки POST-запросов. Если раньше использовался CSRF-токен единой авторизации, его нужно заменить на стандартный bitrix_sessid_post() для каждой формы. Это защитит страницы от подделки запросов после отключения единой авторизации.
Для регистрации необходимо включить проверку обязательных полей через $APPLICATION->AddHeadScript() с кастомными скриптами валидации. Это исключает некорректные запросы на сервер и ускоряет обработку данных. Обязательно проверяйте наличие EMAIL и LOGIN до вызова CUser::Add(), иначе могут возникнуть ошибки при создании пользователя.
После обновления форм авторизации подключите стандартные компоненты Битрикс system.auth.form и system.register.form с вашими изменениями. Убедитесь, что пути редиректа на страницы personal и registration success настроены индивидуально, иначе пользователи будут возвращаться на устаревшие страницы.
Наконец, проверьте работу страниц в разных браузерах и устройствах. Особое внимание уделите мобильной версии: поля ввода, кнопки и уведомления должны корректно отображаться и обрабатывать данные без ошибок после отключения единой авторизации.
Проверка работы пользовательских прав после отключения
После отключения единой авторизации необходимо убедиться, что права пользователей корректно применяются и не нарушают доступ к функционалу.
- Создайте тестовые учетные записи для каждого уровня доступа, включая администратора, менеджера и обычного пользователя.
- Войдите в систему под каждой учетной записью и зафиксируйте доступные разделы административной панели и публичной части сайта.
- Сравните фактические права с настройками в Настройках пользователей → Группы пользователей:
- Проверьте, что пользователи не имеют доступа к разделам, ограниченным их группой.
- Убедитесь, что разрешения на создание, редактирование и удаление элементов соответствуют установленным.
- Проверьте работу функционала с привязкой к контенту: документы, инфоблоки, формы. Для каждой группы убедитесь, что:
- Ограниченные элементы скрыты или недоступны для редактирования.
- Разрешенные действия выполняются без ошибок.
- Используйте инструмент Проверка прав доступа в административной панели для точной диагностики отдельных объектов.
- Зафиксируйте результаты проверки в таблице, чтобы отследить несоответствия и исправить их в настройках групп.
- При обнаружении ошибок очистите кэш сайта и повторите тестирование, так как кеширование может сохранять старые права.
Регулярная проверка после изменения схем авторизации помогает избежать случайного предоставления избыточных прав и снижает риск нарушения безопасности системы.
Тестирование сценариев входа для разных групп пользователей
После отключения единой авторизации важно проверить корректность доступа для всех категорий пользователей. Рекомендуется разделить тестирование на три группы: администраторы, сотрудники и клиенты.
- Администраторы:
- Попытка входа через стандартную форму Битрикс с верными учетными данными.
- Проверка доступа к разделу «Настройки пользователей» и «Журнал действий».
- Вход с неверным паролем и подтверждение отображения точного сообщения об ошибке.
- Проверка восстановления пароля через встроенный механизм.
- Сотрудники:
- Вход через отдельную учетную запись с ограниченными правами.
- Проверка доступа к корпоративным документам и календарю без возможности редактирования настроек системы.
- Попытка доступа к административным разделам и подтверждение блокировки.
- Тестирование работы функции «Запомнить меня» и корректного выхода из системы.
- Клиенты:
- Вход через форму на внешней странице сайта.
- Проверка доступа к личному кабинету, истории заказов и профилю без возможности изменения системных настроек.
- Попытка авторизации с неверными данными и контроль отображения ошибки без утечки информации о системе.
- Тестирование функции сброса пароля и подтверждение получения письма с инструкциями.
Для каждой группы рекомендуется вести журнал тестов с указанием даты, учетной записи, сценария входа и результата. Это позволит быстро выявлять ошибки после внесения изменений в настройки авторизации.
Дополнительно можно использовать скрипты автоматизации для повторного тестирования всех сценариев после обновлений системы, чтобы исключить регрессии.
Резервное копирование и откат настроек при ошибках
Перед отключением единой авторизации создайте полную резервную копию базы данных и папки /bitrix. Для базы данных используйте команду mysqldump -u [пользователь] -p [имя_бд] > backup.sql. Для файловой структуры выполните архивирование каталога сайта: tar -czf bitrix_backup.tar.gz /путь/к/сайту.
Сохраните отдельный файл конфигурации dbconn.php и auth.php, чтобы восстановить текущие параметры подключения и авторизации. Это позволит вернуться к рабочему состоянию без потери пользовательских данных.
После внесения изменений тестируйте функционал авторизации на тестовом поддомене или локальной копии сайта. Проверяйте вход для разных типов пользователей, включая администраторов и внешние сервисы, интегрированные через API.
Если обнаружены ошибки, выполните откат базы данных командой mysql -u [пользователь] -p [имя_бд] < backup.sql и распакуйте файлы из архива: tar -xzf bitrix_backup.tar.gz -C /путь/к/сайту. После восстановления проверьте права доступа к файлам и корректность подключений в dbconn.php.
Регулярное создание резервных копий перед любыми изменениями авторизации сокращает время восстановления и минимизирует риск потери данных. Ведите отдельный журнал изменений конфигурации с отметкой даты и описанием внесённых корректировок.
Вопрос-ответ:
Что означает отказ от единой авторизации в Битрикс?
Отказ от единой авторизации предполагает, что пользователи каждого раздела сайта будут иметь отдельные учетные записи, а не одну общую. Это позволяет разграничить доступ и настройки для разных сайтов или подсайтов, предотвращая автоматическую синхронизацию пользователей между ними.
Какие шаги нужно выполнить, чтобы отключить единую авторизацию в Битрикс?
Процесс включает несколько этапов: сначала необходимо перейти в административную панель и отключить опцию "Единая авторизация" в настройках пользователей. Затем следует проверить, что все интеграции и модули, зависящие от общей учетной записи, перенастроены на локальные учетные записи. После этого стоит протестировать регистрацию и вход на каждом сайте отдельно, чтобы убедиться, что учетные записи функционируют независимо.
Как отключение единой авторизации повлияет на пользователей?
Пользователи больше не смогут использовать один логин и пароль для нескольких сайтов или подсайтов. Им придется создавать отдельные учетные записи для каждого ресурса. Это может увеличить количество регистраций, но при этом повысит контроль над доступом и позволит гибче управлять правами пользователей на разных платформах.
Нужно ли переносить существующих пользователей после отключения единой авторизации?
Если на сайте уже есть пользователи, перед отключением единой авторизации нужно создать механизм миграции. Например, можно разделить их учетные записи по каждому сайту и синхронизировать пароли, чтобы пользователи могли войти без необходимости повторной регистрации. Без этого некоторые пользователи могут потерять доступ к своим данным.
Есть ли риски при отказе от единой авторизации?
Да, основной риск — это сбой доступа пользователей и нарушение работы интеграций, которые используют общие учетные записи. Также важно учитывать, что администраторы теперь будут управлять пользователями отдельно для каждого сайта, что требует внимательности при настройке прав и ролей. Перед внесением изменений стоит создать резервную копию базы данных и протестировать все процессы на тестовой среде.
Загрузка...
