Свой веб интерфейс к 1С: побеждаем CORS на IIS, сохраняя авторизацию

Публикация № 1110191

Администрирование - Администрирование данных 1С

Инструкция Администрирование IIS веб-интерфейс SPA CORS веб сервисы odata

54
Если "веб морда" расположена не по тому же адресу, что и публикация 1С (что часто бывает, например, при разработке, публикация 1С на http://localhost/1c, а разрабатываемое веб-приложение на http://localhost:8080) или, например, мы заходим на веб приложение то по ip адресу, то по имени сервера, или просто веб сервер и сервер, на котором опубликована 1С - это разные сервера, то для большинства запросов от браузера к 1С срабатывает политика CORS, которая заключается в том, что браузер сначала посылает запрос OPTIONS, на который сервер должен ответить определенным образом, заголовками, содержащими разрешения, а потом уже (если разрешение есть), браузер посылает основной запрос. В случае, когда в публикации 1С (default.vrd) жестко прописан логин и пароль, разрулить ситуацию можно средствами 1С. В случае же, когда нужно сохранить авторизацию (или используется стандартный интерфейс odata), начинаются проблемы.

В консоли браузера в это время будет наблюдаться такая картина:

Что такое CORS и зачем он нужен, можно почитать здесь: https://habr.com/post/337146/.


Рассмотрим случай 1:

В default.vrd жестко указан пользователь. Тогда можно воспользоваться только средствами 1с. К каждому шаблону URL добавляем обработчик для HTTP метода OPTIONS

с примерно таким кодом:

Процедура ЗаполнитьЗаголовки(Запрос, Ответ)
	
	Origin = Запрос.Заголовки.Получить("Origin");
	Если Origin = Неопределено Тогда
		Ответ.Заголовки.Вставить("Access-Control-Allow-Origin", "*");
	Иначе
		Ответ.Заголовки.Вставить("Access-Control-Allow-Origin", Origin);
	КонецЕсли;	
	Ответ.Заголовки.Вставить("Access-Control-Allow-Headers", "Authorization,Content-type");
	Ответ.Заголовки.Вставить("Access-Control-Allow-Methods", "GET, POST, PUT");// и какие там еще есть методы у данного шаблона запроса
	
КонецПроцедуры

Функция ШаблонOptions(Запрос)
	
	Ответ = Новый HTTPСервисОтвет(200);
	ЗаполнитьЗаголовки(Запрос, Ответ);
	Возврат Ответ;
	
КонецФункции

и все, теперь можно слать ajax запросы прямо из браузера к http сервисам 1с.

Теперь же рассмотрим случай 2:

у нас нет возможности управлять ответом 1с, например мы стучимся в стандартный интерфейс odata или у нас требуется авторизация, (на которую требуется разрешение на которое требуется авторизация...). В этом случае можно настроить IIS соответствующим образом. Для этого нужно сначала установить "установщик веб платформы" :) Для IIS. Кстати, полезная штука. Позволяет, например, быстро установить php так, что он работает из коробки. Для этого нужно пройти на сайт майкрософт и скачать оттуда дистрибутив. https://www.microsoft.com/ru-RU/download/details.aspx?id=6164. Почему это средство сразу не встроено в консоль управления IIS - не понятно. Очень сильно во многих случаях облегчает жизнь.

После установки запускаем Диспетчер служб IIS, теперь у нас появился новый пункт в настройках.

Запускаем его, в поиске вбиваем cors и получаем невзрачный результат:

Нажимаем "добавить, установить, принимаю, далее, далее, готово", получаем сообщение об успешной установке.

Теперь находим в дереве нашу публикацию, нажимаем на "Редактор конфигурации":

Заходим в раздел system.webServer/cors:

Затем в редакторе указываем enabled в true,

потом проваливаемся в загадочный пункт "(Коллекция)", нажимаем "добавить", заполняем данные:

allowCredentials:true // это как раз разрешение на отправку логина и пароля, для авторизации в 1с.

allowed: true

allowHeaders->allowAllRequestedHeaders: true // можно разрешить заголовки клиента по списку, но особого применения в плане использования с 1с я не вижу

allowMethods: коллекция, добавляем в неё все используемые нами методы, например у меня в добавок к GET и POST используются PUT, LOCK и UNLOCK

и самое главное: origin: тут указываем то, что будет в строке браузера (до первого слеша, для инфостарта это //shop.erpgroup.ru), при использовании нашего веб интерфейса. Например если мы разрабатываем фронт и используем вебпак с чем-то похожим на "npm run dev", то в большинстве случаев тут будет http://localhost:8080.

 

Повторяем для всех адресов origin, которые могут использоваться. К сожалению, использовать wildcard * для запросов с именами авторизацией (где передаются имена пользователей и пароли) нельзя. После этого не забываем нажать на "Применить" в правом верхнем углу и все, должно заработать. Однако, если мы имеем случай 1 из данной статьи (жестко забитый в default.vrd пользователь 1с), то вместо конкретного origin можно указать * и все будет работать.

Надеюсь, эта статья будет полезна.

54

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Labotamy 20.08.19 13:12 Сейчас в теме
Спасибо! С Апачем все почти тривиально, а вот как решать в IIS ответа не встречал.
2. swenzik 20.08.19 14:34 Сейчас в теме
(1) примерно так же как в апаче, кладёшь в папку публикации web.config с содержимым
<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <system.webServer>
   <httpProtocol>
     <customHeaders>
       <add name="Access-Control-Allow-Origin" value="*" />
     </customHeaders>
   </httpProtocol>
 </system.webServer>
</configuration>
Показать

устанавливаемый модуль в IIS делает тоже самое, по сути это гуйный конфигуратор
3. Fragster 922 20.08.19 14:53 Сейчас в теме
(2) не совсем. customHeaders работает для случая 1 из статьи, но нет возможности использовать авторизацию для нескольких origin, например.
4. Labotamy 20.08.19 19:03 Сейчас в теме
(2)Access-Control-Allow вряд-ли полечит отсутствие options в odata
5. Labotamy 20.08.19 22:45 Сейчас в теме
А пусть для Апача тоже тут полежит.
 RewriteEngine On                  
 RewriteCond %{REQUEST_METHOD} OPTIONS 
 RewriteRule ^(.*)$ $1 [R=200,L,E=HTTP_ORIGIN:%{HTTP:ORIGIN}]]
A_Max; Fragster; JohnyDeath; +3 Ответить
6. Yashazz 2522 21.08.19 11:13 Сейчас в теме
Ценно. Один раз методом тыка смог победить, спасибо за нормальное систематизированное описание.
Оставьте свое сообщение