В практике Integrator.Digital регулярно встречаются нестандартные проблемы с Битрикс24, причины которых невозможно определить по одному симптому. За внешне простой ошибкой могут скрываться особенности конфигурации сервера, настройки системы или сразу несколько независимых факторов, влияющих друг на друга.
Подобные ситуации нередко возникают после вмешательства специалистов без достаточного опыта работы с коробочными версиями. Ошибка может появиться после неаккуратной доработки Битрикс24, переноса проекта на новый сервер или изменения конфигурации портала, если исполнитель не учитывает его архитектуру и взаимосвязь компонентов.
Исходная ситуация
За помощью обратилась клиника семейной медицины из Московской области. Инфраструктура клиента была построена на коробочной версии Битрикс24 с двумя сайтами, размещенными на одном ядре.
Сбой проявлялся одинаково у всех пользователей. После ввода логина и пароля система открывала нужный раздел. Любой следующий переход по сайту снова возвращал сотрудника на страницу входа.
Сценарий выглядел так:
-
пользователь открывает сайт и проходит авторизацию;
-
получает доступ к нужному разделу;
-
переходит по ссылке внутри сайта;
-
снова видит форму входа;
-
повторно вводит учетные данные.
Проверка показала, что проблема воспроизводится на разных устройствах и во всех популярных браузерах. Такой результат позволил исключить ошибки на их стороне и сосредоточиться на серверной части.
Что выявила диагностика
К поиску причины специалисты подошли последовательно, проверяя каждую гипотезу до ее подтверждения или исключения. В результате удалось обнаружить несколько факторов, одновременно влияющих на работу авторизации.
Проверка механизма хранения сессий
Диагностика началась с проверки хранения PHP-сессий. В конфигурации Apache был указан каталог /tmp/php_sessions/ext_www/crm.name.clinic, однако фактически такая директория на сервере отсутствовала.
Выяснилось, что вместо указанного пути PHP сохранял данные в стандартный каталог /tmp/php_sessions/www. При этом сервер не выдавал ошибок и продолжал обрабатывать запросы в штатном режиме. Сайт открывался, а журналы не содержали сообщений, указывающих на проблему.
В итоге при каждом запросе создавалась новая гостевая сессия, а система не могла использовать данные ранее авторизованного пользователя. Создание отсутствующего каталога и настройка прав доступа позволили восстановить нормальное хранение сессий.
Проверка настроек cookie
Следующим этапом стала проверка cookie, отвечающих за сохранение данных авторизации. Анализ показал, что идентификатор сессии PHPSESSID записывался для неправильного домена.
Авторизация выполнялась успешно, однако при последующих запросах браузер передавал cookie не тому домену, который использовался для обработки запросов. Из-за этого сервер не мог связать пользователя с действующей сессией и воспринимал его как нового.
Анализ настроек доменов
Следующий этап диагностики привел к одной из самых неожиданных находок во всем проекте. Проверка настроек cookie не дала ответа на вопрос, почему система использует неправильный домен. Чтобы разобраться в ситуации, специалисты перешли к изучению кода ядра Битрикс24.
Во время анализа удалось установить, что домен для cookie определяется через функцию getCookieDomain(), которая обращается к таблице b_lang_domain. Именно здесь и скрывался источник ошибки. В базе данных присутствовали два домена: crm.name.clinic для CRM и name.clinic для основного сайта клиники.
Изучение логики функции показало, что домены сортировались по длине — от коротких к длинным. После этого система выбирала первое подходящее совпадение. Поскольку name.clinic являлся родительским доменом для crm.name.clinic, он обнаруживался раньше и использовался для записи cookie — именно это приводило к неправильному определению домена.
Кроме этого, выявили отсутствие поля DOMAIN_LENGTH в таблице b_lang_domain, хотя код использовал его при сортировке записей. В таблице b_lang также не было значения SERVER_NAME, участвующего в определении параметров сайта.
Специалисты добавили недостающие параметры, заполнили нужные значения и изменили порядок обработки доменов. После внесенных изменений система начала использовать домен, соответствующий текущему сайту, что позволило устранить ошибку авторизации.
Проверка параметра session_auth_only
После исправления домена cookie браузер начал получать правильный идентификатор сессии, однако авторизация по-прежнему не сохранялась между переходами по страницам. Поиск продолжился в самом Битрикс24.
Оказалось, что в настройках Битрикс24 был включен параметр session_auth_only. Его назначение заключается в создании новой авторизованной сессии после входа пользователя с одновременным завершением предыдущей гостевой сессии.
Тестирование показало, что браузер продолжал использовать старый идентификатор сессии, который сервер уже считал недействительным. В результате пользователь снова попадал на страницу авторизации, несмотря на успешный вход.
После отключения параметра session_auth_only конфликт был устранен, а механизм авторизации начал функционировать штатно.
Почему поиск причины занял больше времени, чем исправление
Главная сложность заключалась в том, что сбой не имел одной конкретной причины. На сохранение авторизации одновременно влияли настройки хранения PHP-сессий, параметры cookie, механизм определения домена в коде Битрикс24 и настройка session_auth_only.
Сервер продолжал обрабатывать запросы, страницы нормально открывались, а форма входа функционировала в штатном режиме. При этом авторизация продолжала сбрасываться, а журналы не содержали сообщений, которые могли бы сразу указать на источник неисправности.
Специалистам пришлось последовательно проверить весь путь авторизации — от хранения PHP-сессий на сервере до логики Битрикс24, определяющей домены и обработку входа в систему.
Краткие итоги
Доработка Битрикс24 позволяет адаптировать систему под задачи компании, автоматизировать новые процессы и расширять стандартные возможности платформы. Однако любые изменения важно выполнять с учетом особенностей конкретного проекта и внутренней архитектуры портала.
Практика показывает, что ошибки в настройках, переносе или доработке могут проявляться спустя длительное время и затрагивать совершенно другие механизмы, чем те, которые изменялись изначально. По этой причине подобные задачи лучше доверить сертифицированным партнерам Битрикс24, обладающим подтвержденной экспертизой в работе с платформой.
Integrator.Digital выполняет диагностику, доработку и сопровождение коробочных версий Битрикс24, разрабатывает модули, интеграции и любой нестандартный функционал для потребностей бизнеса.
