Публикация информационной базы «1С:Предприятие» на веб-сервере — стандартная задача, с которой сталкивается практически каждый системный администратор или разработчик 1С. Однако процесс интеграции платформы с веб-сервером Microsoft Internet Information Services (IIS) версии 8.5 под управлением Windows Server 2012 R2 таит в себе множество скрытых нюансов. Неправильное распределение прав доступа, конфликты разрядности пулов приложений и особенности авторизации HTTP-сервисов могут привести к досадным сбоям.
В этой статье мы подробно и пошагово разберем, как избавиться от распространенной ошибки HTTP 403.14 - Forbidden, выясним природу сбоя авторизации HTTP 401.5 при обращении к HTTP-сервисам (например, HealthCheck) и рассмотрим безопасные архитектурные варианты настройки беспарольного доступа к API вашей базы данных.
Типичная ситуация: публикация базы в Конфигураторе проходит штатно и без предупреждений, в целевом каталоге (например, C:\inetpub\wwwroot\buh_test\) создается файл описания публикации default.vrd, но при попытке открыть базу через браузер по адресу http://localhost/buh_test/ сервер выдает ошибку:
«HTTP Error 403.14 - Forbidden. The Web server is configured to not list the contents of this directory».
Эта ошибка означает, что веб-сервер IIS воспринимает ваш запрос как попытку просмотреть физическое содержимое папки на диске. Это происходит из-за того, что IIS не понимает, что входящий запрос предназначен для обработки специальным модулем расширения 1С (wsisapi.dll). Рассмотрим основные шаги, которые помогут решить эту проблему.
Шаг 1. Запуск Конфигуратора от имени Администратора
Основная причина возникновения этой ошибки заключается в недостатке прав у платформы 1С в момент выполнения публикации. Если запустить 1С обычным двойным кликом, у процесса не хватит привилегий для изменения конфигурационных файлов веб-сервера IIS.
Для исправления ситуации выполним следующие действия:
1cv8.exe).Запуск с повышенными правами позволяет платформе корректно создать конфигурационный файл web.config в каталоге публикации, а также зарегистрировать необходимые обработчики запросов непосредственно в метаданных IIS.
Шаг 2. Проверка ограничений ISAPI и CGI на уровне сервера IIS
Если запуск от имени администратора не помог, веб-сервер может блокировать работу динамической библиотеки 1С по соображениям безопасности. Нам необходимо вручную проверить глобальные разрешения IIS:
wsisapi.dll для используемой версии платформы. Путь должен выглядеть примерно так: C:\Program Files\1cv8\8.3.11.2924\bin\wsisapi.dll.Шаг 3. Конфигурирование разрядности пула приложений IIS
Разрядность пула приложений IIS, обслуживающего веб-публикацию, должна строго соответствовать разрядности установленной платформы 1С. Если вы используете 64-битную платформу 1С, пул приложений должен работать в 64-битном режиме, и наоборот. Проверим эту настройку:
DefaultAppPool, либо пул с именем вашей публикации).---
После успешной публикации базы при попытке обратиться к кастомному HTTP-сервису (например, по URL http://localhost/buh_test/hs/HealthCheck) вы можете столкнуться с окном авторизации, а затем со следующей ошибкой:
«The URL you tried to reach has an ISAPI or CGI application installed that verifies user credentials before proceeding. This application cannot verify your credentials».
Технически это код ошибки 401.5, который означает, что IIS попытался взять на себя аутентификацию пользователя для внешней библиотеки, но не смог сопоставить переданные реквизиты со своей внутренней базой учетных записей Windows или Active Directory.
Выясним причину конфликта и устраним ее с помощью правильной настройки подсистем авторизации.
Шаг 1. Отключение лишних методов аутентификации в IIS
Для того чтобы IIS беспрепятственно передавал заголовки авторизации напрямую в платформу 1С (которая сама прекрасно умеет проверять логины и пароли пользователей ИБ), нам необходимо отключить все методы проверки подлинности IIS на уровне виртуального каталога, кроме анонимного доступа.
Sites -> Default Web Site -> buh_test.buh_test и в центральной части откроем раздел «Проверка подлинности» (Authentication).Таким образом, IIS перестанет пытаться проверять учетные данные пользователей своими силами и полностью делегирует авторизацию платформе 1С.
Шаг 2. Настройка NTFS-прав на системные папки 1С
Для стабильной работы модуля расширения веб-сервера необходимо предоставить процессам IIS права на запуск исполняемых файлов платформы 1С. Настроим права доступа к каталогу платформы:
C:\Program Files\1cv8\ (или к C:\Program Files (x86)\1cv8\ в случае использования 32-битной версии).8.3.11.2924) и откроем «Свойства», перейдем на вкладку «Безопасность».IIS_IUSRS и нажмем «ОК».IUSR с такими же правами.wsisapi.dll.---
Рассмотрим ситуацию, когда к вашему HTTP-сервису HealthCheck обращаются сторонние внешние системы мониторинга или интеграционные вебхуки. Зачастую они не умеют или не должны каждый раз отправлять интерактивные запросы ввода логина и пароля. Мы можем настроить бесшовную авторизацию несколькими способами. Проанализируем каждый из них.
Мы можем отредактировать конфигурационный файл публикации default.vrd, прописав в параметрах подключения имя и пароль пользователя 1С, под которым веб-сервер будет автоматически авторизовать любые входящие анонимные запросы.
Разберем этот процесс по шагам:
C:\inetpub\wwwroot\buh_test\.default.vrd, нажмем правой кнопкой мыши и откроем его с помощью любого текстового редактора (например, Notepad++).<point> и его атрибут ib, содержащий строку подключения к базе данных.Usr (Имя пользователя 1С) и Pwd (Пароль пользователя 1С). Обратите внимание на необходимость использования XML-сущности " вместо обычных двойных кавычек внутри атрибута.Проанализируем структуру измененного файла для файлового варианта работы:
<?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="/buh_test"
ib="File="C:\Base";Usr="WebMonitor";Pwd="SuperSecretPassword";">
<ws>
<point name="WebServices" alias="ws.1c" enable="true"/>
</ws>
<httpServices publishByDefault="true"/>
</point>
А теперь посмотрим на пример для клиент-серверного варианта базы данных:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/buh_test"
ib="Srvr="Server1C";Ref="buh_test_db";Usr="WebMonitor";Pwd="SuperSecretPassword";">
<httpServices>
<service name="HealthCheck" alias="HealthCheck" enable="true"/>
</httpServices>
</point>
Важное предупреждение: Данный метод имеет критический недостаток в области безопасности. Если по этой же ссылке http://localhost/buh_test/ вы планируете предоставлять доступ пользователям через веб-клиент 1С, то любой человек, открывший данный адрес в браузере, автоматически зайдет в базу данных под учетной записью WebMonitor без ввода пароля!
Если нам необходимо разграничить доступ к веб-клиенту и к HTTP-сервисам, мы можем использовать встроенный механизм заголовков HTTP Basic Authentication. При этом в файле default.vrd логин и пароль по умолчанию указывать не нужно.
Внешнее приложение при отправке запросов должно передавать авторизационные данные непосредственно в URL-адресе в следующем формате:
http://WebMonitor:SuperSecretPassword@localhost/buh_test/hs/HealthCheck
Либо внешняя система должна сформировать стандартный HTTP-заголовок запроса:
Authorization: Basic V2ViTW9uaXRvcjpTdXBlclNlY3JldFBhc3N3b3Jk
Где строка V2ViTW9uaXRvcjpTdXBlclNlY3JldFBhc3N3b3Jk представляет собой закодированную в Base64 комбинацию Логин:Пароль.
Примечание: для обеспечения безопасности передаваемых данных при использовании Basic Auth настоятельно рекомендуется настроить на IIS шифрование трафика (протокол HTTPS) и получить SSL-сертификат. В противном случае пароли будут передаваться по сети в открытом виде.
Выясним наиболее гибкий и безопасный способ организации доступа. Если внешнее интегрируемое приложение не умеет работать со стандартной авторизацией, а светить пароли в файле default.vrd или в URL-адресах небезопасно, мы можем развернуть перед веб-сервером IIS быстрый прокси-сервер Nginx.
Схема взаимодействия выглядит следующим образом:
Authorization: Basic ... с зашифрованными учетными данными служебного пользователя 1С.Рассмотрим пример конфигурационного файла Nginx (nginx.conf) для реализации такой схемы проксирования:
server {
listen 80;
server_name monitoring.company.local;
location /buh_test/hs/HealthCheck {
# Перенаправляем запрос на локальный IIS
proxy_pass http://127.0.0.1:8080/buh_test/hs/HealthCheck;
# Подменяем заголовки хоста
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# Автоматически внедряем заголовок авторизации 1С (WebMonitor:SuperSecretPassword)
# Значение "V2ViTW9uaXRvcjpTdXBlclNlY3JldFBhc3N3b3Jk" получено кодированием в Base64
proxy_set_header Authorization "Basic V2ViTW9uaXRvcjpTdXBlclNlY3JldFBhc3N3b3Jk";
}
# Все остальные запросы (например, к веб-клиенту) проксируем без изменений авторизации
location /buh_test/ {
proxy_pass http://127.0.0.1:8080/buh_test/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
В этой конфигурации веб-сервер IIS должен быть перенастроен на работу на альтернативном внутреннем порту (например, 8080), а Nginx займет стандартные внешние порты. При такой архитектуре мы надежно скрываем авторизационные реквизиты 1С внутри защищенной конфигурации Nginx, предоставляя внешнему миру простой, беспарольный и безопасный доступ к конкретной точке интеграции.