Прошу пояснить за CORS в отношении панели X-UI, почему ошибка?

Question

[Иннокентий Иванов]

Есть такая панель для ныне актуальных способов обхода роскомнадзора.

Схема такая: все серты есть, панель крутится в докере и слушает 443, при необходимости редиректит на порт с NGINX, а тот показывает статику какую-нибудь.

На других портах что только ни торчит... На 40000 SS, gRPC на 1234, подписки на 2096, но нас интересует API на 55555.

Я в этот API могу постучаться Postman'ом, браузером и его расширениями, в том числе скриптами Tampermonkey.

Проблема в том, что я не могу достучаться до 55555 из своего веб-приложения на Angular на локалхосте! Ошибка CORS.

Как её решить? Вот что пробовал:

• туннелировал через ngrok, zrok и т. д.
  
• Расширения браузера, позволяющие добавлять CORS, не помогли
  
• Проксировал через Cors.io (или подобных), добавляя его к урлу с API
  
• в самом Ангуляре создавал проксю, есть там такая фича
  

Ничего не помогает. Как быть? Я плохо понимаю механизм CORS. Почему моему приложению нельзя притвориться, будто оно работает от постмана или от скрипта в браузере?

Comments

[Drno]

Ваше приложение в трм же докер контейнере? Иначе почему Вы стучитель на локалхост?

[Иннокентий Иванов]

NGINX, certbot и X-UI обитают в docker-контейнерах с режимом network_mode: host, то есть прямо в сети сервера, а всё потому, что X-UI будет торчать наружу вообще через любые рандомные порты от 80 до 65532. Значит, и остальные контейнеры будут в том же network_mode.

Да, стучусь на локалхост, когда захожу по SSH на сервер.

Answer 1

[Rsa97]

Всё очень просто. Если страница в браузере загрузилась с одного источника (пусть это будет основное приложение), а обращается к другому (пусть это будет API), то включается защита CORS, встроенная в браузер. Разными считаются источники у которых что-то отличается: протокол (http / https), доменное имя и/или порт.
Для обхода защиты API должен возвращать ответ с набором CORS-заголовков, разрешающих, как минимум, конкретный тип запроса (GET, POST, OPTIONS и т.п.) и источник основного приложения.
Если API принадлежит не вам и вы не в состоянии установить нужные заголовки ответа прямо на нём, то единственный вариант - проксировать запрос через свой бэкенд с добавлением заголовков. То есть, ваша страница делает запрос к вашему бэкенду, ваш бэкенд запрашивает стороннее API, получает от него ответ и возвращает его вашей странице.

Comments

[Иннокентий Иванов]

Понял. Допустим, проксирующий бэкенд (например, NGINX) будет работать на порту 55556, а API на 55555... Может сработать. Спасибо! Попробую это реализовать. О результатах напишу.