REST API CORS

У тебя есть хоть какой-нибудь прогресс? Похоже, нужен бекенд уровня intermediate.

Я написал Dockerfile для /container, который может это сделать, используя официальный контейнер NGINX с настройкой обратного прокси для CORS. Если нужно, посмотрите моё сообщение на форуме: «Mginx» Container — обратный прокси для поддержки CORS и X.509 на базе Nginx. Правка: надо проверять свои сообщения — не X506, а X.509, и не “wrote”, а “wrote”.

Не могли бы вы подробнее рассказать, как вы это сделали? Мне нужно сделать что-то похожее.

Да, это действительно открывает новые возможности. Термин «расточительно» очень подходит. Я давно хотел включить в бренд-кит статическую .html-страницу с небольшим JS, который напрямую вызвал бы RouterOS с этой страницы — без серверной части, без контейнера, чтобы всё работало локально на CPE. Но отсутствие даже CORS с политикой «same-origin» означает, что нужен бэкенд и/или обратный прокси для CORS. Ранее я отправлял официальную заявку на добавление этой функции (SUP-99112) и получил примерно такой ответ: «посмотрим, что можно сделать» — так что есть хоть какой-то положительный сдвиг.

Конкретно я предложил добавить в /ip/services галочку для включения этой функции вместе со списком FQDN для «разрешённых источников», которые возвращаются REST API, чтобы поддерживать схему CORS*. На стороне клиента всё равно придётся танцевать с CORS (например, использовать includeCredentials: true и так далее в fetch()/XMLHttpRequest), но это уже решаемо. Отсутствие CORS-заголовков от REST-сервера — вот в чём проблема.

*на клиентской стороне много правил CORS, поэтому заголовок cors-allowed-origin не может быть «*», если используются креденшелы, а RouterOS требует авторизацию (например, basic auth)… значит REST API должен как-то обращаться с источниками.