Что делать если на каждый хит теряется авторизация? Простому пользователю проще будет написать в техподдержку. А разработчик сайта может сам легко продиагностировать эту проблему не дожидаясь ответа техподдержки. Для гуру веб разработок материал, возможно, будет не очень интересен. А для тех, кто хочет такими стать, предлагаю доступное изложение работы механизма авторизации. Когда поступает обращение в техподдержку с такой проблемой, мы классифицируем его как простое. Потому что понимая механизм работы авторизации можно быстро локализовать проблему. В частых вопросах коротко описаны основные проблемы, хочу показать обоснование. Как это работает В своей основе технология веб сайтов (протокол HTTP) не предполагает идентификацию пользователей: соединение с сервером не поддерживается, каждый переход по страницам - новое подключение к веб серверу. Чтобы различать запросы в php используется механизм сессий. Принцип следующий: при первом заходе на сайт посетителю присваивается уникальный идентификатор (идентификатор сессии, далее PHPSESSID), браузер сохраняет его у себя, сервер хранит некоторую информацию для этого идентификатора (например о том, что он авторизован). Затем при каждом новом переходе вся сохранённая информация (данные сессии) читаются интерпретатором php и передаются скрипту. А значит проблемы начнутся когда: сервер не выдаст ID, клиент не сохранит ID или сервер не сохранит данные сессии. Как проверить PHPSESSID передаётся через заголовки HTTP - эта часть служебной информации, которая не показывается браузером. Для её просмотра нужно использовать специальные инструменты (бесплатные), самые популярные: прокси сервер Fiddler, плагины FireFox FireBug и livehttpheaders. Последний - простой плагин, которым я воспользуюсь для иллюстрации вопроса. Через меню инструменты делаю открываю окно "Live HTTP Headers" и делаю первый хит на сайт (все куки очистил). Подсветкой выделил ключевую строку (часть идентификатора скрыл с тем чтобы у особо пытливых читателей не было соблазна ходить под моей сессией). Здесь сервер указал, что мне следует сохранить в куки PHPSESSID. Если этого не произошло - дальше ничего не пойдёт. Верный признак проблемы: в заголовке нет ни одной записи Set-Cookie. В подавляющем большинстве случаев это говорит о том, что до старта сессии был вывод на экран. После этого php не может изменить заголовки HTTP. Типичный пример из файла /bitrix/php_interface/dbconn.php: define("CACHED_menu", 3600); ?> <? define("BX_FILE_PERMISSIONS", 0644); Здесь закрывается php тегом ?>, потом идёт перенос строки, который разработчики часто игнорируют, затем продолжение скрипта. Но нельзя забывать, что перенос строки (равно как и пробел) - это начало формирования тела страницы, а значит заголовки HTTP уже выставлены не будут. Тоже самое в начале и конце файла не должно быть никаких посторонних символов. Правильно: define("CACHED_menu", 3600); ?><? define("BX_FILE_PERMISSIONS", 0644); или просто define("CACHED_menu", 3600); define("BX_FILE_PERMISSIONS", 0644); Также надо обратить внимание на файл init.php в этой папке, к нему те же требования. Может быть ситуация, когда проблема в настройках сервера, это легко проверить нашим скриптом: bitrix_server_test.php (чтобы сессии работали на сервере нужна поддержка сессий в php, указана папка сохранения сессий и у php были права на запись в эту папку). Работа с куками Кука была сохранена, то на следующий хит браузер должен передать PHPSESSID на сервер. запрос на сервер с PHPSESSID Редко встречаются проблемы в работе браузеров, чаще идентификатор не передаётся в результате неправильного сохранения. Поясню. На прошлом изображении в строке Set-Cookie есть запись: domain= 1c-bitrix.ru . Она определяет, на какой домен будет распространяться кука. Для браузеров действуют простые правила безопасности: - нельзя сохранить куку в другом домене. Например, сайт 1c-bitrix.ru не может выставить куку для домена mail.ru , если домен не будет соответствовать - она просто будет отброшена; - куки из верхнего домена распространяются на поддомены. Например, указали 1c-bitrix.ru , открываем dev.1c-bitrix.ru или www.1c-bitrix.ru - кука должна передаваться. Наоборот не будет работать: кука домена www.1c-bitrix.ru не подхватится на 1c-bitrix.ru . - если не указан домен - кука привязывается к текущему домену, но не распространяется на поддомены. Битрикс указывает домен в куки из настроек сайта. А значит убедитесь, что в настройках сайта указаны правильные домены (поле Доменное имя). На этот и все последующие хиты в ответе сервера кука PHPSESSID не должна выдаваться: ответ сервера Если браузер передал PHPSESSID, а сервер всё равно выдал новый, значит он либо не сохранил сессию у себя (проверить папку и права на неё, часто бывает неправильно указан путь в windows, используются обратные слешы \ вместо прямых /) либо сессия истекла и сервер её удалил (между хитами должно пройти какое-то время). Если тест сервера показывает, что сохранение сессий работает, сессии PHPSESSID сохраняется и передаётся, но авторизация всё равно теряется, значит проблема в настройках битрикса. Приходилось сталкиваться с ситуацией, когда интернет-провайдер периодически меняет IP адрес клиента, тогда срабатывает настройка привязки к IP в настройках безопасности группы пользователей. В этом случае следует установить привязку 0.0.0.0. Это основные проблемы, встречаются экзотические ситуации, но очень редко. Большинство проблем с авторизацией, а также сохранением данных с ошибкой Ваша сессия истекла или Ошибка безопасности диагностируются как показано здесь.
Компания АКРИТ
Как решить проблему неработающей авторизации?
Что делать если на каждый хит теряется авторизация? Простому пользователю проще будет написать в техподдержку. А разработчик сайта может сам легко продиагностировать эту проблему не дожидаясь ответа техподдержки. Для гуру веб разработок материал, возможно, будет не очень интересен. А для тех, кто хочет такими стать, предлагаю доступное изложение работы механизма авторизации.
Когда поступает обращение в техподдержку с такой проблемой, мы классифицируем его как простое. Потому что понимая механизм работы авторизации можно быстро локализовать проблему. В частых вопросах коротко описаны основные проблемы, хочу показать обоснование.
Как это работает
В своей основе технология веб сайтов (протокол HTTP) не предполагает идентификацию пользователей: соединение с сервером не поддерживается, каждый переход по страницам - новое подключение к веб серверу.
Чтобы различать запросы в php используется механизм сессий. Принцип следующий: при первом заходе на сайт посетителю присваивается уникальный идентификатор (идентификатор сессии, далее PHPSESSID), браузер сохраняет его у себя, сервер хранит некоторую информацию для этого идентификатора (например о том, что он авторизован). Затем при каждом новом переходе вся сохранённая информация (данные сессии) читаются интерпретатором php и передаются скрипту.
А значит проблемы начнутся когда: сервер не выдаст ID, клиент не сохранит ID или сервер не сохранит данные сессии.
Как проверить
PHPSESSID передаётся через заголовки HTTP - эта часть служебной информации, которая не показывается браузером. Для её просмотра нужно использовать специальные инструменты (бесплатные), самые популярные: прокси сервер Fiddler, плагины FireFox FireBug и livehttpheaders. Последний - простой плагин, которым я воспользуюсь для иллюстрации вопроса.
Через меню инструменты делаю открываю окно "Live HTTP Headers" и делаю первый хит на сайт (все куки очистил).
Подсветкой выделил ключевую строку (часть идентификатора скрыл с тем чтобы у особо пытливых читателей не было соблазна ходить под моей сессией).
Здесь сервер указал, что мне следует сохранить в куки PHPSESSID. Если этого не произошло - дальше ничего не пойдёт. Верный признак проблемы: в заголовке нет ни одной записи Set-Cookie. В подавляющем большинстве случаев это говорит о том, что до старта сессии был вывод на экран. После этого php не может изменить заголовки HTTP. Типичный пример из файла /bitrix/php_interface/dbconn.php:
define("CACHED_menu", 3600);
?>
<?
define("BX_FILE_PERMISSIONS", 0644);
Здесь закрывается php тегом ?>, потом идёт перенос строки, который разработчики часто игнорируют, затем продолжение скрипта. Но нельзя забывать, что перенос строки (равно как и пробел) - это начало формирования тела страницы, а значит заголовки HTTP уже выставлены не будут. Тоже самое в начале и конце файла не должно быть никаких посторонних символов. Правильно:
define("CACHED_menu", 3600);
?><?
define("BX_FILE_PERMISSIONS", 0644);
или просто
define("CACHED_menu", 3600);
define("BX_FILE_PERMISSIONS", 0644);
Также надо обратить внимание на файл init.php в этой папке, к нему те же требования.
Может быть ситуация, когда проблема в настройках сервера, это легко проверить нашим скриптом: bitrix_server_test.php (чтобы сессии работали на сервере нужна поддержка сессий в php, указана папка сохранения сессий и у php были права на запись в эту папку).
Работа с куками
Кука была сохранена, то на следующий хит браузер должен передать PHPSESSID на сервер.
запрос на сервер с PHPSESSID
Редко встречаются проблемы в работе браузеров, чаще идентификатор не передаётся в результате неправильного сохранения. Поясню. На прошлом изображении в строке Set-Cookie есть запись:
domain= 1c-bitrix.ru . Она определяет, на какой домен будет распространяться кука. Для браузеров действуют простые правила безопасности:
- нельзя сохранить куку в другом домене. Например, сайт 1c-bitrix.ru не может выставить куку для домена mail.ru , если домен не будет соответствовать - она просто будет отброшена;
- куки из верхнего домена распространяются на поддомены. Например, указали 1c-bitrix.ru , открываем dev.1c-bitrix.ru или www.1c-bitrix.ru - кука должна передаваться. Наоборот не будет работать: кука домена www.1c-bitrix.ru не подхватится на 1c-bitrix.ru .
- если не указан домен - кука привязывается к текущему домену, но не распространяется на поддомены.
Битрикс указывает домен в куки из настроек сайта. А значит убедитесь, что в настройках сайта указаны правильные домены (поле Доменное имя).
На этот и все последующие хиты в ответе сервера кука PHPSESSID не должна выдаваться:
ответ сервера
Если браузер передал PHPSESSID, а сервер всё равно выдал новый, значит он либо не сохранил сессию у себя (проверить папку и права на неё, часто бывает неправильно указан путь в windows, используются обратные слешы \ вместо прямых /) либо сессия истекла и сервер её удалил (между хитами должно пройти какое-то время).
Если тест сервера показывает, что сохранение сессий работает, сессии PHPSESSID сохраняется и передаётся, но авторизация всё равно теряется, значит проблема в настройках битрикса. Приходилось сталкиваться с ситуацией, когда интернет-провайдер периодически меняет IP адрес клиента, тогда срабатывает настройка привязки к IP в настройках безопасности группы пользователей. В этом случае следует установить привязку 0.0.0.0.
Это основные проблемы, встречаются экзотические ситуации, но очень редко. Большинство проблем с авторизацией, а также сохранением данных с ошибкой Ваша сессия истекла или Ошибка безопасности диагностируются как показано здесь.