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.
Это основные проблемы, встречаются экзотические ситуации, но очень редко. Большинство проблем с авторизацией, а также сохранением данных с ошибкой Ваша сессия истекла или Ошибка безопасности диагностируются как показано здесь.
Битрикс: не могу авторизоваться. в чем моя ошибка?
Перенес сайт штатными средствами битрикса через архивы и файл restore.php
Перенес на хостинг таймвеба милениум.
сайт работает быстро, bitrix_server_test зелененький, но не пускает в админку.
раза с 6-10 авторизует. но нажав на какую либо ссылку снова выбрасывает на авторизацию. чистил кеш, чистил куки.
куки вроде ставятся верно. пробовал с FF, YandexChrome, с андройда , с ифона, с винфона. везде одинаковое поведение. человек из екатеринбурга авторизовался, все ок. проблем нет. но в калининграде, не хотит ни в какую ))) у меня уже нет идей куда копать )))
пробовалась вайфай сеть, 4г сеть.