Перейти к содержимому
BXWiki

Авторизация через соцсети в 1С-Битрикс (socialservices)

Модуль социальных сервисов добавляет вход и регистрацию через внешние сервисы по протоколу OAuth. Настройка выглядит простой, но состоит из нескольких шагов, и ошибка в любом из них ломает вход целиком.

Как это работает

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

Приложение регистрируется у провайдера. Для каждого сервиса нужно завести отдельное приложение в кабинете разработчика и получить пару ключей - идентификатор и секрет. Без зарегистрированного приложения вход через этот сервис не работает в принципе.

Ключи вводятся в одном месте - на странице настроек модуля, где у каждого провайдера свой блок.

Адрес обратного вызова копируется из интерфейса модуля, а не придумывается. У части провайдеров это фиксированный служебный обработчик платформы, у остальных - значение из настроек модуля. Именно этот адрес прописывают в приложении у провайдера - и он же типичная точка для CSRF-атаки: проверку прав и CSRF разбирает статья об основах безопасности.

Примеры

1. Порядок подключения провайдера

  1. Зарегистрировать приложение в кабинете разработчика сервиса.
  2. Скопировать адрес обратного вызова из настроек модуля и вписать его в приложение.
  3. Получить идентификатор и секрет приложения.
  4. Внести их в блок соответствующего провайдера в настройках модуля.
  5. Включить провайдера и проверить вход в приватном окне браузера.

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

2. Вывод кнопок входа

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

3. Сопоставление аккаунтов

Модуль связывает внешний аккаунт с пользователем сайта. Ключевой сценарий, о котором стоит подумать заранее: посетитель уже зарегистрирован по почте, а потом входит через сервис с тем же адресом. Поведение в таких случаях зависит от настроек и от того, отдаёт ли провайдер подтверждённый адрес почты, - этот сценарий стоит проверить до запуска.

Справочник

ЭлементНазначениеОсобенности
Приложение у провайдерадоступ к OAuthсвоё для каждого сервиса
Идентификатор и секретключи приложениявводятся в настройках модуля
Адрес обратного вызовакуда провайдер возвращает пользователякопируется из интерфейса модуля
Страница настроек модуляключи всех провайдерову каждого свой блок
Служебный обработчик платформыфиксированный адрес возвратау части провайдеров
Сопоставление аккаунтовсвязь внешнего профиля с пользователемпродумать сценарий совпадения почты
Компонент авторизациикнопки входавыводит доступных провайдеров

Частые ошибки

Адрес обратного вызова придуман вручную. Провайдер вернёт ошибку несовпадения - адрес нужно копировать из интерфейса модуля.

Ключи от тестового приложения на боевом сайте. Домены не совпадают, и вход падает на возврате.

Провайдер включён, но приложение не зарегистрировано. Кнопка есть, вход не работает.

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

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

Забывают про смену домена. При переезде на другой домен адреса обратного вызова нужно обновить у всех провайдеров.

Частые вопросы

Где взять адрес обратного вызова?

В интерфейсе модуля - он там показан и оттуда копируется. Придумывать его нельзя: у части провайдеров это фиксированный служебный обработчик платформы, у остальных - значение из настроек модуля. Ошибка в этом адресе даёт отказ на стороне провайдера при возврате пользователя.

Что происходит, если у пользователя уже есть аккаунт с такой же почтой?

Зависит от настроек и от того, отдаёт ли провайдер подтверждённый адрес почты. Возможны и сопоставление с существующим пользователем, и создание нового. Это ровно тот сценарий, который стоит проверить до запуска: иначе постоянные клиенты будут получать вторые аккаунты и терять историю заказов.

Нужно ли регистрировать приложение для каждого сервиса?

Да, у каждого провайдера своё приложение со своей парой ключей, и заводится оно в кабинете разработчика этого сервиса. Общего ключа не существует. Плюс помните, что приложения привязаны к домену - для тестового и боевого сайта обычно нужны разные.

Кнопка входа есть, но ничего не происходит. Что проверить?

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

Связанные темы

Первоисточники