Стандартный интерфейс OData (REST API) в платформе 1С — это мощный инструмент для интеграции со сторонними системами. Однако при его публикации на веб-серверах Apache или IIS администраторы часто сталкиваются со специфическими техническими сбоями. Типичный сценарий: веб-клиент 1С работает абсолютно нормально, но при попытке обратиться к ресурсу OData в браузере или через внешнее приложение мы получаем либо критическую ошибку 1С:Предприятия, связанную с падением сеанса, либо пустую страницу с кодом 500/503 без окна ввода логина и пароля.
В этой статье мы подробно проанализируем причины возникновения ошибок веб-сервера при работе с OData, разберем архитектуру взаимодействия компонентов и пошагово исправим все неполадки.
Рассмотрим ситуацию, с которой часто сталкиваются специалисты. При попытке перейти по адресу публикации OData (например, http://site.ru/basename/odata/standard.odata/) браузер возвращает следующую системную ошибку:
1C:Enterprise 8 application error:
Невосстановимая ошибка
by reason:
Сеанс отсутствует или удален ID=1f51a981-364a-4934-9c2b-145f3290fde7, File=src\ClusterDistribImpl.cpp(1436)
При этом в некоторых браузерах (например, в Firefox) отображается ошибка с кодом 503, а в Internet Explorer или Chrome — ошибка 500 (Internal Server Error). Важный момент: стандартное окно ввода логина и пароля 1С при этом даже не появляется. Выясним, почему это происходит и как вернуть работоспособность интеграционному интерфейсу.
Ошибка, указывающая на файл ClusterDistribImpl.cpp (или аналогичный сбой в clusterdistribimpl.cpp на серверах под управлением Windows), сообщает нам о том, что веб-сервер успешно передал запрос расширению платформы 1С, но на уровне кластера серверов 1С произошел критический сбой инициализации или удержания сеанса.
Проанализируем основные факторы, вызывающие этот сбой:
SYSTEM, Local System или Network Service), а в информационной базе 1С включена аутентификация операционной системы для некоторых пользователей, платформа пытается выполнить автоматический «тихий» вход. Поскольку системная учетная запись компьютера не сопоставлена ни с одним реальным пользователем 1С, механизм авторизации завершается аварийно еще до вызова диалогового окна.default.vrd. По умолчанию при публикации OData генерируется директива reuseSessions="autouse". Этот параметр предписывает платформе использовать пул уже существующих HTTP-сеансов для ускорения работы. Если один из сеансов в пуле «умер» или был аварийно завершен на сервере 1С (например, из-за нехватки памяти или таймаута), последующие запросы OData будут пытаться обратиться к этому несуществующему идентификатору (ID сессии), вызывая лавинообразное появление ошибки «Сеанс отсутствует или удален».Разберем по шагам, как устранить аварийное завершение сеансов в кластере 1С.
Если вы используете веб-сервер Apache под управлением Windows, по умолчанию его служба работает от имени системы. Нам необходимо перенастроить службу так, чтобы она работала от имени специально созданного локального пользователя (например, usr1cv8), который не имеет доменных привилегий и никак не связан со сквозной авторизацией ОС в 1С. Для этого откройте оснастку «Службы» (Services), найдите службу Apache, перейдите в свойства на вкладку «Вход в систему» (Log On) и укажите данные локального пользователя.
Посмотрим на структуру файла default.vrd, который находится в папке публикации вашей базы на веб-сервере. Нам необходимо изменить настройки повторного использования сеансов. Откроем файл в текстовом редакторе и найдем секцию standardOdata.
Заменим параметр reuseSessions="autouse" на reuseSessions="dontuse". Это заставит платформу инициализировать чистый сеанс для каждого нового запроса, что исключит обращение к некорректным кэшированным ID сессий в кластере. Пример правильной конфигурации секции:
<standardOdata enable="true"
reuseSessions="dontuse"
sessionMaxAge="20"
poolSize="10"
poolTimeout="5"/>
Важное примечание: отключение пула сессий (параметр dontuse) может незначительно снизить скорость обработки единичных запросов OData, однако это гарантирует стабильность работы и устраняет ошибку в ClusterDistribImpl.cpp. Если стабильность восстановилась, в дальнейшем можно попробовать вернуть параметр autouse, но предварительно увеличив poolTimeout.
После изменения параметров обязательно остановите службу сервера 1С:Предприятия и веб-сервер Apache. Очистите серверный кэш (папки snccntry и временные файлы в каталоге службы сервера 1С), после чего запустите службы заново.
Вторая проблема, с которой часто сталкиваются разработчики: веб-сервер при обращении к OData возвращает ошибку 500, но окно для авторизации в браузере не появляется. В то же время, если прописать логин и пароль непосредственно в файле публикации default.vrd или передать их в строке запроса, все начинает работать.
Выясним причину такого поведения. Для того чтобы браузер показал пользователю стандартную форму ввода логина и пароля, веб-сервер при первом (анонимном) запросе должен вернуть ответ со статусом 401 Unauthorized и специальным HTTP-заголовком WWW-Authenticate. Этот заголовок указывает браузеру доступные методы авторизации.
В некоторых релизах платформы 1С 8.3 (включая ветку 8.3.14) присутствует подтвержденный баг. При обработке запроса к сервисам OData платформа формирует некорректный заголовок WWW-Authenticate (в нем отсутствует обязательный параметр realm или значение заголовка повреждено). Современные браузеры с жесткими требованиями к безопасности (Chrome, Firefox) при получении поврежденного заголовка безопасности прерывают соединение и выдают ошибку 500/503 вместо отображения окна авторизации.
Рассмотрим подробнее три основных способа обхода и устранения этой проблемы.
Поскольку проблема с заголовком WWW-Authenticate является внутренней ошибкой платформы 1С, наиболее правильным и долгосрочным решением является обновление технологической платформы 1С:Предприятие до актуального стабильного релиза (ошибка была исправлена в более поздних сборках веток 8.3.15 и выше).
Если обновить платформу в данный момент невозможно, мы можем обойти баг, настроив автоматическую авторизацию на стороне веб-сервера. Для этого в файле default.vrd можно явно прописать имя пользователя и пароль специально созданной служебной учетной записи 1С, под которой будут выполняться все запросы к OData. У этого пользователя в информационной базе должны быть настроены минимально необходимые права на чтение требуемых объектов метаданных.
Проанализируем пример файла default.vrd с жестко заданными учетными данными:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/mybasename"
ib="Srvr="myservername";Ref="mybasename";">
<ws enable="false"/>
<httpServices publishByDefault="false"/>
<standardOdata enable="true"
reuseSessions="dontuse"
usr="ODataServiceUser"
pwd="MySecretPassword123"/>
</point>
При такой настройке веб-сервер при каждом запросе будет автоматически авторизоваться в 1С под пользователем ODataServiceUser, и браузеру больше не потребуется запрашивать учетные данные у конечного пользователя.
Если OData используется для интеграции со сторонним приложением (а не для просмотра человеком в браузере), мы можем полностью избежать багов с диалоговым окном авторизации. Для этого внешнее приложение должно отправлять HTTP-заголовок Authorization превентивно (то есть сразу в первом запросе, не дожидаясь ответа 401 от сервера).
Заголовок формируется по стандарту Basic Access Authentication. Например, для пользователя Администратор без пароля строка заголовка в коде внешнего приложения будет выглядеть так:
Authorization: Basic QWRtaW5pc3RyYXRvcjo=
Где часть QWRtaW5pc3RyYXRvcjo= — это закодированная в Base64 строка вида Логин:Пароль.
Также для быстрого тестирования в строке браузера можно передавать учетные данные в самом URL-адресе (хотя данный метод считается устаревшим в современных системах безопасности):
http://ODataServiceUser:MySecretPassword123@site.ru/basename/odata/standard.odata/
Использование любого из этих трех методов позволяет полностью обойти проблему некорректной обработки заголовков авторизации платформой 1С и настроить стабильный обмен данными через протокол OData.