Bitrix http авторизация ошибка не работает

7

12.05.200915:0312.05.2009 15:03:45

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

частых вопросах

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

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

В своей основе технология веб сайтов (протокол 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 на сервер.

Редко встречаются проблемы в работе браузеров, чаще идентификатор не передаётся в результате неправильного сохранения. Поясню. На прошлом изображении в строке 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://forum.hostdvor.com/viewtopic.php?f=35&p=119
http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=35&LESSON_ID=1967 (офсайт)

Форматирование — оригинальное, так что все плевки о грязи в коде — в оригинал.

Ошибка: Не работает авторизация при обмене данными с 1С в Bitrix CMS.

Среда: php 5.3.8 as fcgi SAPI; 

Решение: Часто проблема возникает в результате работы php в режиме FCGI (fast cgi). 
В этом режиме есть проблемы с передачей данных авторизации HTTP в php. Проверить работу HTTP авторизации можете в админ. панели Битрикс -> Рабочий стол -> Настройки -> Инструменты -> Проверка сайта

или по прямой ссылке:

http://имясайта.com/bitrix/admin/site_checker.php

Для решения данной проблемы попробуйте выполнить такие действия:

1) В корне сайта в файл .htaccess добавьте строки:

КОД: ВЫДЕЛИТЬ ВСЁ

RewriteEngine on
RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]

2) Закоментируйте следующие строки в файле bitrix/admin/.htaccess, которые отключают mod_rewrite:

КОД: ВЫДЕЛИТЬ ВСЁ

#<ifmodule mod_rewrite.c="">
# RewriteEngine Off
#</ifmodule>

3. В файл bitrix/php_interface/dbconn.php добавьте строки:

КОД: ВЫДЕЛИТЬ ВСЁ

$remote_user = $_SERVER["REMOTE_USER"] 
? $_SERVER["REMOTE_USER"] : $_SERVER["REDIRECT_REMOTE_USER"];
$strTmp = base64_decode(substr($remote_user,6));
if ($strTmp)
    list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':', $strTmp);

Внимание: на сервере должна быть включена поддержка rewrite rules и правил .htaccess.

Как починить авторизацию, которая начала постоянно слетать после обновления Битрикс

Обновлено: 23 апреля 2021

9718 просмотров

После очередного обновления Битрикса в ноябре 2020 г. пользователи сталкиваются со «слётом» авторизации практически сразу после ввода пароля, то есть их разлогинивает сразу после авторизации.

Проблема с задвоением PHPSESSID (идентификатор сессии php появлялся в cookies браузера дважды) серьёзна, так как у простых посетителей задача «выполнить очистку cookies в браузере» вызовет ступор, а без этого они не смогут нормально авторизоваться.

Поэтому надо инициировать удаление лишних данных из cookie со стороны сервера, для этого впишите куда-нибудь в файл /bitrix/php_interface/dbconn.php (заменив www.site.ru из примера на свой домен):

setcookie("PHPSESSID", "", 777, "/", ".www.site.ru");

setcookie("PHPSESSID", "", 777, "/");

Если вам пришла идея переопределить название идентификатора «PHPSESSID» на уровне настроек PHP, что бы обойти проблему — это плохая идея, которая вызовет трудноотлавливаемые проблемы.

Надеюсь, эта статья помогла решить вашу проблему!

Разместили проект не на выделенке, а на шареде. В целях, известных одному

Богу

хостеру, php там бегает не как mod_php, а как php-cgi/fcgi.

Сразу же после размещения проекта на хостинге советую проверить настройки сайта — /bitrix/admin/site_checker.php?lang=ru

По результатам проверки на себя обратила внимание ошибка HTTP-авторизации, в связи с тем, что в ее описании отмечено, что она мешает обмену с базой 1С и «другому функционалу».

И действительно — выгрузка не идет. Причина — скорее всего в отсутствии HTTP-авторизации. Решение для починки следующее:
1. Убеждаемся что на сервере есть mod_rewrite и прописываем в .htaccess строки:

RewriteEngine on
RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]

Вообще, в .htaccess, поставляемом с Битриксом эти строки уже есть, но убедиться лишний раз стоит.

2. Далее отключаем отключение (!) реврайта в административном разделе: комментируем в /bitrix/admin/.htaccess весь блок с модулем mod_rewrite:

#<ifmodule mod_rewrite.c>
# RewriteEngine Off
#</ifmodule>

3. В init.php дописываем код:

$remote_user = $_SERVER["REMOTE_USER"]? 
    $_SERVER["REMOTE_USER"] : $_SERVER["REDIRECT_REMOTE_USER"];
$strTmp = base64_decode(substr($remote_user,6));
if ($strTmp)
    list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = 

        explode(':', $strTmp);

Можно пробовать выгрузку. В моем случае все заработало.

Решение взято с сайта битрикса, там же описано еще несколько типовых проблем с выгрузкой из 1С.

Проблема авторизации в Битрикс

	 BitrixMainDBSqlQueryException] 
	 Mysql query error: (145) Table './.../b_sec_session' is marked as crashed and should be repaired (400)
	 SELECT 



  


                       
  



	 `security_session`.`SESSION_DATA` AS `SESSION_DATA`
	 FROM `b_sec_session` `security_session` 
	 WHERE `security_session`.`SESSION_ID` = 'l5fvkBD94rIlLuP05j16I0VvEM7ZfncC'
	 LIMIT 0, 1

Возврат к списку