Проблема блокировки чтения из-за перекрестного источника (CORB) с KrakenD - ответ "application / json" из POST отклонен Chrome - PullRequest
Новая
       44

Проблема блокировки чтения из-за перекрестного источника (CORB) с KrakenD - ответ "application / json" из POST отклонен Chrome

0 голосов
/ 31 октября 2019

auth.js: 84 Блокировка перекрестного источника (CORB) заблокировала ответ перекрестного источника http://myserver/auth с приложением MIME-типа / json.

Это неработать с Firefox, хотя сообщение об ошибке Firefox является более общим. Как ни странно, панель «Сеть» Firefox показывает, что нужный мне ответ действительно получен, браузер просто не принимает ответ, чтобы передать его в мой код JavaScript.

Это настройка CORS из моего krakend.jsonfile: 

        "github_com/devopsfaith/krakend-cors": {
            "allow_origins": ["http://localhost:61552"],
            "allow_headers": ["Origin", "Authorization", "Content-Type", "Accept", "X-Auth-Token", "Referer", "User-Agent"],
            "expose_headers": ["Content-Type", "Content-Length"],
            "allow_credentials": true,
            "allow_methods": ["GET", "HEAD", "POST", "OPTIONS"]
        }

И это конкретная конечная точка, которая вызывается: 

    "endpoints": [{
            "endpoint": "/auth",
            "method": "POST",
            "output_encoding": "no-op",
            "extra_config": {
                "github.com/devopsfaith/krakend-ratelimit/juju/router": {
                    "maxRate": 20,
                    "clientMaxRate": 8,
                    "strategy": "ip"
                }
            },
            "backend": [{
                "url_pattern": "/connect/token",
                "encoding": "no-op",
                "sd": "dns",
                "host": ["identity-server.service.consul"],
                "disable_host_sanitize": true
            }]
        },

Мой запрос JavaScript выглядит так: 

    xhr.open('POST', url);
    xhr.setRequestHeader('Accept', 'application/json');
    xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    xhr.withCredentials = true;
    xhr.onreadystatechange = function () {
       ...
    }

    xhr.send(...

Я думал о попыткеизмените тип содержимого ответа на text/plain в случае, если это поможет, но в настоящее время у меня нет доступа к коду, который генерирует этот ответ, и я не знаю, поможет ли это в любом случае.

Когда я делаю этот же запрос с сервера node.js или из приложения, такого как Postman, все возвращается правильно, и заголовки, которые я хотел бы увидеть, на мой взгляд, должны быть достаточными для того, чтобы CORS был счастлив (access-control-allow-credentials: true)access-control-allow-origin: *)

1 Ответ

0 голосов
/ 01 ноября 2019

Я наконец нашел ответ на этот вопрос.

Первая проблема заключалась в том, что при использовании xhr.withCredentials = true недостаточно получить заголовок ответа access-control-allow-origin: *. Заголовок ответа должен содержать исходное происхождение самого запроса, например access-control-allow-origin: https://example.com.

Вторая проблема заключалась в том, как модуль CORS, используемый kraken, работает с подстановочными доменами. Если вы используете "allow_origins": [] или "allow_origins": ["*"], сервер отвечает access-control-allow-origin: *, несмотря ни на что.

Однако я не хотел помещать в белый список все хосты, которые могут захотеть использовать этот сервер.

К счастью, кто-то смог указать мне на исходный код, используемый kraken для обработки CORS (на https://github.com/rs/cors),, и получается, что если вы используете любой другой вид подстановочного выражения, отличный от "*"для всего, например "http*", сервер возвращает эхом исходный хост, и все хорошо! Моя конфигурация теперь:

"allow_origins": ["http*"]

ПРИМЕЧАНИЕ. Это может быть опасно ! Если вы помещаете конфиденциальные данные в файлы cookie, эти же данные могут стать доступными для любых других веб-сайтов таким образом.

...