Назад | Перейти на главную страницу

CORS заблокирован параметром No «Access-Control-Allow-Origin» в докеризованном приложении Angular внешнего интерфейса и серверном интерфейсе Spring Boot, подключенном к докеру.

Я создал приложение Angular и создал образ докера, который позволяет ему запускаться на сервере Nginx (после его запуска). Для бэкэнда у меня также есть dockerized реализация. При попытке получить доступ к данным из бэкэнда я сталкиваюсь с ошибкой в ​​отношении политики CORS, так что в браузере я вижу следующее: «... был заблокирован политикой CORS: Нет» Access-Control-Allow -Оригинал "заголовок присутствует ..."

Чтобы решить эту проблему, я пробовал различные изменения конфигурации на сервере Nginx, например: (1) установка add_header «Access-Control-Allow-Origin» «http://0.0.0.0:8080», (2) попытка аналогичного изменения на стороне прокси, proxy_set_header «Access-Control-Allow-Origin» «http://0.0.0.0:8080» и т. д., но ни один из них не работал (обратите внимание, с «http: //0.0. 0.0: 8080 "относится к бэкэнду, тогда как к Angular, имеющему доступ через" http://0.0.0.0:7000 ").

Пример того, как выглядит мой файл конфигурации, приведен ниже:

server { 
    listen 80;
    location / {
        root /usr/share/nginx/html;
        index index.html index.htm;
        try_files $uri $uri /index.html = 404;
    }

    location /api {
         proxy_pass http://0.0.0.0:8080;
         proxy_set_header "Access-Control-Allow-Origin" "http://0.0.0.0:8080"
     }
}

Не могли бы вы поделиться идеями о том, как решить эту проблему?

Спасибо!

Им не нужно добавлять что-либо в nginx conf, например proxy_set_header. Вы должны добавить фильтр происхождения CORS в свое веб-приложение Spring и разрешить из другого источника.

Как это :

@Component
@Order(Ordered.HIGHEST_PRECEDENCE)
@Slf4j
public class CorsFilter implements Filter {

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        final HttpServletResponse response = (HttpServletResponse) res;
        log.info("request came for url {}", ((HttpServletRequest) req).getRequestURL());
        response.setHeader("Access-Control-Allow-Origin", "*");
        response.setHeader("Access-Control-Allow-Methods", "POST, PUT, GET, OPTIONS, DELETE");
        response.setHeader("Access-Control-Allow-Headers", "Authorization, Content-Type");
        response.setHeader("Access-Control-Max-Age", "3600");
        if (HttpMethod.OPTIONS.name().equalsIgnoreCase(((HttpServletRequest) req).getMethod())) {
            response.setStatus(HttpServletResponse.SC_OK);
        } else {
            chain.doFilter(req, res);
        }
    }

    @Override
    public void destroy() {
    }

    @Override
    public void init(FilterConfig config) throws ServletException {
    }
}

Именно веб-клиент (где бы ни находился заблокированный веб-клиент в вашей настройке) выполняет фактическую блокировку, поэтому вам необходимо разрешить исходный адрес, который клиент намеревается использовать с введенным Access-Control-Allow-Origin заголовок.

Этот заголовок и значение должны быть известны клиенту до отправки запроса (который не выполняется для вас), поэтому более ранний ответ должен предоставить его.

Как видно из ссылки, синтаксис заголовка не включает номера портов. Насколько мне известно, 0.0.0.0 - это не синтаксис, который CORS интерпретирует так же, как сетевые службы, но не тестировал это и может ошибаться.

Насколько я знаю, заголовок также не определяет протокол, а только fqdn, например. www.example.com.

Я бы предположил, что конкретный IP-адрес может работать вместо fqdn, но не тестировал это и мог ошибаться.

Однако я использовал синтаксис подстановочных знаков (*), указанный в ссылке, и это действительно работает. По возможности предпочтительнее указывать более конкретный адрес, но можно начать с подстановочного знака и сначала убедиться, что внедрение заголовка работает.

Так что попробуйте вводить Access-Control-Allow-Origin: * мое предложение.