Перехват сеанса в веб-клиенте 1С — это серьезная проблема безопасности и стабильности работы системы. Когда один пользователь после выхода из личного кабинета непреднамеренно «передает» свой сеанс следующему сотруднику, это указывает на некорректную обработку идентификаторов сессий на уровне веб-сервера. Давайте разберем, почему это происходит и как мы можем локализовать причину.
Прежде всего, нам необходимо исключить влияние веб-сервера. Если в клиентском приложении (толстый или тонкий клиент) проблема не воспроизводится, значит, логика работы самой платформы 1С:Предприятие в части аутентификации работает корректно. Проблема кроется в способе доставки HTTP-запросов от браузера к серверу 1С.
Рекомендуем выполнить следующие действия:
Apache. Если проблема исчезнет, значит, причина заключается в специфических настройках пула приложений IIS или кэшировании на стороне IIS.1С назначает тот же номер сеанса, что был освобожден ранее, необходимо выяснить, не происходит ли «подхват» этого номера через кэшированные куки (cookies) браузера или настройки IIS.Частой причиной «перехвата» является кэширование статического контента или ответов от сервера приложений 1С. Если IIS отдает ответ, сформированный для предыдущего сеанса, браузер может ошибочно применить его к новому контексту. Убедитесь, что для опубликованной базы отключено кэширование на уровне HTTP-заголовков. Мы должны быть уверены, что каждый запрос проходит обработку в wsapsp.dll (модуль расширения 1С) без промежуточного сохранения состояния на сервере.
Для корректной изоляции пользователей в IIS необходимо настроить отдельные пулы приложений (Application Pools). Проверьте параметры переработки (Recycle) пула — если пул перезапускается слишком часто или, наоборот, удерживает состояние (connection pooling) некорректно, это может приводить к смешиванию идентификаторов. Рекомендуем выделить базу ЗКГУ в отдельный пул с собственным удостоверением пользователя.
Поскольку вы используете доменную аутентификацию, важно помнить о механизме Negotiate/Kerberos. Браузеры (Chrome, Edge) могут автоматически передавать учетные данные текущего пользователя Windows. Если в IIS включена «Анонимная проверка подлинности» вместе с «Проверкой подлинности Windows», возможны конфликты контекстов безопасности. Рекомендуем отключить анонимный доступ и оставить только Windows Authentication, чтобы исключить попытки сервера работать под учетной записью IUSR или пула приложений.
Веб-клиент 1С использует файлы cookies для поддержания связи с сеансом. Проверьте, не происходит ли «склейка» сессий из-за того, что браузеры на разных машинах используют одинаковые параметры безопасности или идентификаторы. Попробуйте очистить кэш браузера и куки перед входом, а также проверьте настройки безопасности SameSite в IIS. В ряде случаев, если IIS настроен некорректно, он может возвращать один и тот же Set-Cookie заголовок для разных соединений.
Версия платформы 8.3.17 является достаточно зрелой, но в более свежих версиях 1С были внесены критические исправления в механизм работы веб-клиента и управления сеансами. Если инфраструктурные настройки не дают результата, обязательно рассмотрите возможность обновления до текущей версии LTS. Часто исправления внутренних ошибок 1С при работе через веб-серверы закрывают проблему «призрачных» сеансов на уровне самой платформы.
Для глубокого анализа используйте технологический журнал (ТЖ). Настройте фильтры на события CONN (соединения) и SCALL (вызовы серверов). Если вы зафиксируете, что два разных IP-адреса обращаются к одному и тому же внутреннему номеру сеанса, вы получите неоспоримое доказательство того, что проблема лежит на инфраструктурном уровне, и сможете передать эти логи сетевым инженерам для дальнейшего расследования.