1С-Битрикс Разработчикам – Как решить проблему неработающей авторизации?

Что делать если на каждый хит теряется авторизация? Простому пользователю проще будет написать в техподдержку. А разработчик сайта может сам легко продиагностировать эту проблему не дожидаясь ответа техподдержки. Для гуру веб разработок материал, возможно, будет не очень интересен. А для тех, кто хочет такими стать, предлагаю доступное изложение работы механизма авторизации.

[spoiler]

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

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

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

В своей основе технология веб сайтов (протокол HTTP) не предполагает идентификацию пользователей: соединение с сервером не поддерживается, каждый переход по страницам – новое подключение к веб серверу.
Чтобы различать запросы в php используется механизм сессий. Принцип следующий: при первом заходе на сайт посетителю присваивается уникальный идентификатор (идентификатор сессии, далее PHPSESSID), браузер сохраняет его у себя, сервер хранит некоторую информацию для этого идентификатора (например о том, что он авторизован). Затем при каждом новом переходе вся сохранённая информация (данные сессии) читаются интерпретатором php и передаются скрипту.
А значит проблемы начнутся когда: сервер не выдаст ID, клиент не сохранит ID или сервер не сохранит данные сессии.

Как проверить

PHPSESSID передаётся через заголовки HTTP – эта часть служебной информации, которая не показывается браузером. Для её просмотра нужно использовать специальные инструменты (бесплатные), самые популярные: , плагины FireFox и . Последний – простой плагин, которым я воспользуюсь для иллюстрации вопроса.

Через меню инструменты делаю открываю окно “Live HTTP Headers” и делаю первый хит на сайт (все куки очистил):

Подсветкой выделил ключевую строку (часть идентификатора скрыл с тем чтобы у особо пытливых читателей не было соблазна ходить под моей сессией).
Здесь сервер указал, что мне следует сохранить в куки PHPSESSID. Если этого не произошло – дальше ничего не пойдёт. Верный признак проблемы: в заголовке нет ни одной записи Set-Cookie. В подавляющем большинстве случаев это говорит о том, что до старта сессии был вывод на экран. После этого php не может изменить заголовки HTTP. Типичный пример из файла /bitrix/php_interface/dbconn.php:

Здесь закрывается php тегом

?>

, потом идёт перенос строки, который разработчики часто игнорируют, затем продолжение скрипта. Но нельзя забывать, что перенос строки (равно как и пробел) – это начало формирования тела страницы, а значит заголовки HTTP уже выставлены не будут. Тоже самое в начале и конце файла не должно быть никаких посторонних символов. Правильно:

или просто

Также надо обратить внимание на файл

init.php

в этой папке, к нему те же требования.

Может быть ситуация, когда проблема в настройках сервера, это легко проверить нашим скриптом:

(чтобы сессии работали на сервере нужна поддержка сессий в php, указана папка сохранения сессий и у php были права на запись в эту папку).

Работа с куками

Кука была сохранена, то на следующий хит браузер должен передать PHPSESSID на сервер.

Редко встречаются проблемы в работе браузеров, чаще идентификатор не передаётся в результате неправильного сохранения. Поясню. На прошлом изображении в строке Set-Cookie есть запись:
domain=1c-bitrix.ru. Она определяет, на какой домен будет распространяться кука. Для браузеров действуют простые правила безопасности:

– нельзя сохранить куку в другом домене. Например, сайт 1c-bitrix.ru не может выставить куку для домена mail.ru, если домен не будет соответствовать – она просто будет отброшена;
– куки из верхнего домена распространяются на поддомены. Например, указали 1c-bitrix.ru, открываем vhod-v-lichnyj-kabinet.ru или – кука должна передаваться. Наоборот не будет работать: кука домена не подхватится на 1c-bitrix.ru.
– если не указан домен – кука привязывается к текущему домену, но не распространяется на поддомены.

Битрикс указывает домен в куки из настроек сайта. А значит убедитесь, что в настройках сайта указаны правильные домены (поле Доменное имя).

На этот и все последующие хиты в ответе сервера кука PHPSESSID не должна выдаваться:

Если браузер передал PHPSESSID, а сервер всё равно выдал новый, значит он либо не сохранил сессию у себя (проверить папку и права на неё, часто бывает неправильно указан путь в windows, используются обратные слешы вместо прямых /) либо сессия истекла и сервер её удалил (между хитами должно пройти какое-то время).

Если тест сервера показывает, что сохранение сессий работает, сессии PHPSESSID сохраняется и передаётся, но авторизация всё равно теряется, значит проблема в настройках битрикса. Приходилось сталкиваться с ситуацией, когда интернет-провайдер периодически меняет IP адрес клиента, тогда срабатывает настройка привязки к IP в настройках безопасности группы пользователей. В этом случае следует установить привязку 0.0.0.0.

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