Битрикс 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.

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

14.08.2015

Во время администрирования сайта столкнулся с тем, что не работает авторизация в систему управления сайта Битрикс. С чем же может быть связано не вхождение в систему?

Характерные признаки проблемы:

• Появляется урл вида: bitrix/admin/index.php?_r=3456#authorize где r=3456 меняется на любое число с каждой попыткой
• Ошибок никаких не выдает
• Вирусов и внедрений на сайте нет.

Основные признаки: похоже на проблему сохранения сессии

Решение проблемы:

В этом конкретном случае сессии хранятся в БД (таблица b_sec_session). Она была повреждена и авторизация не срабатывала. После исправления таблицы авторизация работает.

Нужно восстановить только одну таблицу в базе данных b_sec_session, поможет команда: mysqlcheck -r db_name table_name -uroot -p 

После восстановления таблицы получил такую ошибку (до этого ошибки не выдавались):

	 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



  


                       
  

После этого полностью очистил таблицу b_sec_session и смог авторизоваться

После очистки таблицы также можно будет авторизоваться и исправить повреждения таблицы с помощью встроенных инструментов проверки системы

С чем это связано и как избежать в будущем?    

Таблицы в БД могут повреждаться по разным причинам, лучше уточнить этот момент у администратора сервера/хостинга.

Чтобы увеличить надежность таблиц рекомендуется перевести их в формат InnoDB вместо MyISAM (если эта возможность поддерживается на хостинге). Модуль «монитор производительности» позволяет выполнить эту операцию из административного интерфейса.

Вот ещё чек-лист возможных проблем если пропадает авторизация

https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=35&LESSON_ID=2167&LESSON_PATH=3906.4503.2167

Ещё статьи:

Вопросы надежности и безотказности работы программного обеспечения, помогающего развитию бизнеса, всегда стоят очень остро. Любые, даже самые незначительные ошибки в конечном итоге приводят к неприятностям и упущенной выгоде. Несмотря на то, что поставщики ПО прилагают большие усилия для того, чтобы избежать ошибок в работе своего продукта: активно тестируют приложения перед запуском, своевременно исправляют найденные недочеты — не всегда все бывает гладко.

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

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

Почему так происходит и что делать?

С подобной неприятной ситуацией к нам обратился один из наших клиентов. У сотрудников периодически слетала авторизация во время работы на портале «Битрикс». Мало того, что это оказывало негативное влияние на весь рабочий процесс, так еще и пугало. Что первым делом подумает менеджер, которого во время работы выбрасывает из системы? Что случилось что-то ужасное — его взломали, что все работает неправильно. Вылеты происходили из любого места: сайта, CRM-системы, подключенных приложений.

Когда мы начали разбираться, то выяснилось, что все предложенные поставщиком сервиса стандартные методы решения такой проблемы не дают никакого результата. Авторизация по-прежнему случайным образом слетала, и мы не могли найти этому никакого объяснения. Пришлось начать разбираться более серьезно и потратить на это большое количество времени. В итоге мы выявили причину и смогли повторить ее: проблема оказалась в переменной в cookie, и она актуальна для большинства систем, установленных на одном домене.

Подробное объяснение проблемы и решение

Как мы уже писали выше, эта ошибка связана с дублированием переменной PHPSESSID в cookie. Она возникает в том случае, когда для установки различных продуктов Битрикс используются поддомены одного домена. В качестве примера рассмотрим установку «1С-Битрикс: Управление сайтом» и «1С-Битрикс24: CRM».

Допустим, что в нашем распоряжении находится домен webmagazin.ru, на который мы устанавливаем «1С-Битрикс: Управление сайтом», а для установки CRM-системы мы будем использовать crm.webmagazin.ru. Это как раз тот случай, при котором возможны рандомные вылеты авторизации в системе. Никакие решения, предложенные в Битрикс, в нашем случае не помогали.

В процессе тестирования различных вариантов мы пришли к мнению, что в настоящее время лучшим решением является перенос продуктов на разные домены. К примеру: устанавливаем «1С-Битрикс: Управление сайтом» на webmagazin.ru, а для размещения CRM-системы используем отличный от webmagazin домен второго уровня. Например, webcrm.ru. На данный момент это единственное эффективно работающее средство, помогающее раз и навсегда избавиться от этой проблемы.

Насколько сложно все исправить?

Если у вас возникли проблемы с авторизацией: пользователей выбрасывает из системы, или они по нескольку раз не могут войти в нее, убедитесь, что ваши продукты установлены с соблюдением вышеупомянутых условий — разнесены по разным доменам. Если нет — не страшно. Мы сможем разнести по разным доменам установленные продукты «Битрикс» в самые короткие сроки без необходимости прерывать рабочие процессы, менять привычки, самостоятельно перенастраивать автоматизацию. Все будет работать так же как и прежде, за исключением того, что пропадет ошибка, вызывающая слет авторизации у сотрудников.

Мы более 10 лет занимаемся разработкой, доработкой, а также поиском и устранением ошибок в продуктах «Битрикс». У нас большой опыт, можно сказать, что мы знаем систему изнутри, в мельчайших деталях. Более того, мы не прекращаем ни на минуту совершенствовать свои знания о ней — мы развиваемся вместе с ней. Именно поэтому вы всегда знаем ответы на вопросы, которые не знают другие, а если готовых ответов нет — мы сами находим ответы.

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

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

9491 просмотр

После очередного обновления Битрикса в ноябре 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, что бы обойти проблему — это плохая идея, которая вызовет трудноотлавливаемые проблемы.

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