[spoiler]
Когда поступает обращение в техподдержку с такой проблемой, мы классифицируем его как простое. Потому что понимая механизм работы авторизации можно быстро локализовать проблему. В коротко описаны основные проблемы, хочу показать обоснование.
Как это работает
В своей основе технология веб сайтов (протокол HTTP) не предполагает идентификацию пользователей: соединение с сервером не поддерживается, каждый переход по страницам - новое подключение к веб серверу.
Чтобы различать запросы в php используется механизм сессий. Принцип следующий: при первом заходе на сайт посетителю присваивается уникальный идентификатор (идентификатор сессии, далее PHPSESSID), браузер сохраняет его у себя, сервер хранит некоторую информацию для этого идентификатора (например о том, что он авторизован). Затем при каждом новом переходе вся сохранённая информация (данные сессии) читаются интерпретатором php и передаются скрипту.
А значит проблемы начнутся когда: сервер не выдаст ID, клиент не сохранит ID или сервер не сохранит данные сессии.
Как проверить
PHPSESSID передаётся через заголовки HTTP - эта часть служебной информации, которая не показывается браузером. Для её просмотра нужно использовать специальные инструменты (бесплатные), самые популярные: , плагины FireFox и . Последний - простой плагин, которым я воспользуюсь для иллюстрации вопроса.
Через меню инструменты делаю открываю окно "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 в этой папке, к нему те же требования.
Может быть ситуация, когда проблема в настройках сервера, это легко проверить нашим скриптом: (чтобы сессии работали на сервере нужна поддержка сессий в php, указана папка сохранения сессий и у php были права на запись в эту папку).
Работа с куками
Кука была сохранена, то на следующий хит браузер должен передать PHPSESSID на сервер.
Редко встречаются проблемы в работе браузеров, чаще идентификатор не передаётся в результате неправильного сохранения. Поясню. На прошлом изображении в строке Set-Cookie есть запись:
domain=1c-bitrix.ru. Она определяет, на какой домен будет распространяться кука. Для браузеров действуют простые правила безопасности:
- нельзя сохранить куку в другом домене. Например, сайт 1c-bitrix.ru не может выставить куку для домена mail.ru, если домен не будет соответствовать - она просто будет отброшена;
- куки из верхнего домена распространяются на поддомены. Например, указали 1c-bitrix.ru, открываем dev.1c-bitrix.ru или - кука должна передаваться. Наоборот не будет работать: кука домена не подхватится на 1c-bitrix.ru.
- если не указан домен - кука привязывается к текущему домену, но не распространяется на поддомены.
Битрикс указывает домен в куки из настроек сайта. А значит убедитесь, что в настройках сайта указаны правильные домены (поле Доменное имя).
На этот и все последующие хиты в ответе сервера кука PHPSESSID не должна выдаваться:
Если браузер передал PHPSESSID, а сервер всё равно выдал новый, значит он либо не сохранил сессию у себя (проверить папку и права на неё, часто бывает неправильно указан путь в windows, используются обратные слешы \ вместо прямых /) либо сессия истекла и сервер её удалил (между хитами должно пройти какое-то время).
Если тест сервера показывает, что сохранение сессий работает, сессии PHPSESSID сохраняется и передаётся, но авторизация всё равно теряется, значит проблема в настройках битрикса. Приходилось сталкиваться с ситуацией, когда интернет-провайдер периодически меняет IP адрес клиента, тогда срабатывает настройка привязки к IP в настройках безопасности группы пользователей. В этом случае следует установить привязку 0.0.0.0.
Это основные проблемы, встречаются экзотические ситуации, но очень редко. Большинство проблем с авторизацией, а также сохранением данных с ошибкой Ваша сессия истекла или Ошибка безопасности диагностируются как показано здесь.
Но тогда попутный вопрос. Правильно ли я понимаю, что при работе с локальной копией сайта если не изменить поле "Доменное имя" глюки с авторизацией обеспечены? Ведь на локальной копии доменное имя будет "localhost".
Лично у меня авторизация глючила периодически и нестабильно на разных браузерах как под битриксовским веб-окружением, так и под денвером до тех пора пока я методом проб и ошибок не догадался его просто вычистить.
Если это действительно так, то наверно стоит поместить такую инфу в FAQ.
У меня проблем с авторизацией не было по последнего обновления.
На локальной копии под денвером разрабатывался сайт, а точнее группа сайтов по варианту многосайтовости 2. Это когда для каждого сайта выделяется отдельный каталог.
В каждом сайте были прописаны доменные имена в поле "Доменное имя". Это приводило к нестабильно работающей авторизации. Причем как под денвером, так и под битриксовским веб-окружением. При этом авторизация сначала начинала глючить под FF, но продолжала работать под ИЕ. Потом переставала работать под ИЕ под денвером, но продолжала под веб-окружением. Плюс все это по разному глючило на разных компах.
Самое неприятное, что при проблемах с авторизацией даже резервную копию сайта сделать невозможно.
Все отлично заработало когда я очистил поле "Доменное имя" у всех сайтов. Я так понимаю, что это поле используется только для многосайтовости с судя по всему в механизме авторизации тоже. Пока разработка ведется локально мне это поле и не нужно. Что будет когда размещу в сети пока не знаю.
Но на период разработки я бы советовал это поле не использовать. Слишком уж задолбался с глюками авторизации и в постоянном ожидании, что она вот-вот отвалится.
Удачи
Думаю, может до этого доменное имя было введено неверно, скорее всего где-то русская буква затесалась. Пока домены добавлять не стану.
Насторожила фраза "Проблемы начнутся"
Есть ли какие-нибудь простые рекомендации для того, чтобы они точно не начались?
Имеет ли смысл заполнять поле "Доменное имя" если не предполагается многосайтовость?
Как я понял источник проблем как раз в этом поле.
Попутно пара вопрос скорее в тему многосайтовости, но как мне кажется тоже важные для понимания механизма авторизации:
Как Битрикс на уровне админки узнает какой домен текущий в случае многосайтовости?
Возможна ли локальная разработка и тестирование многосайтовых систем под Веб-окружением? Желательно без проблемм с авторизацией
О! а как его очистить?
Очистить все!
Если с этой галкой включенной, действительно, авторизация немедленно слетает для второго по счету сайта.
разрабатывался каталог по принципу многосайтовости 2: 2 каталога в разных папках.
Фокусы начинались, когда я что-либо добавлял в корзину, потом выходил. Так, пытаясь протестить для разных групп пользователей разные ситуации я в итоге дошел до того, что сессия админа слетала при переходе на другую страницу
кое-как из под другого браузера удалось вычистить всю корзину и зайти, но нервов было потрачено изрядно.
все крутилось на денвере и домены были заданы нормально - но даже очистка кук не помогала - ни слова об ошибке - просто вылет на форму авторизации.
Насколько я понял, битрикс сохраняет содержимое корзины у себя в кеше (но где?) и даже при очищенных куках при повторной авторизации корзина в прежнем состоянии - сомнительное юзабилити (ИМХО)
Еще куки могут не сохраняться при превышении квоты на сервере. Например на ник.ру так.
У меня на локальном сервере слетала авторизация именно из-за того, что доменное имя состояло из 1 слова (например korm), также был назван виртуальный хост. Как только я в Апаче и в Битриксе поменял на korm.bb - авторизация перестала слетать. Веееесьма странно, но факт!
Домен:
Обычно такого не бывает, всегда так делаю, но иногда - ПОЧЕМУ-ТО (???) случается.
помогло.....очень помогло....
Очень помогла, у меня не был указан поддомен при установке кук.
RewriteCond %{THE_REQUEST} ^.*/index\.php
RewriteRule ^(.*)index.php$ /$1 [R=301,L]
Некоторое время не мог понять почему авторизация перестала работать. Потом догадался убрать этот редирект. Может кому-то пригодится. Если ничего не помогает, можно попробовать заглянуть в htaccess
Если у кого-то защищённый или как-то нестандартно настроен сервак, вот вариант:
проверьте переменную
У меня на сайте в domain добавляется точка, из-за этого есть проблемы.
Подскажите, пожалуйста, как убрать точку ?