CORS с 3 шкалой

Мы пытаемся настроить платформу 3scale поверх OpenShift для управления доступом к API между службой REST и веб-приложением JavaScript. Аутентификация должна осуществляться с помощью пользовательского ключа, помещенного в заголовок HTTP. Эти два приложения доступны по разным URL-адресам:

JS web application:     http://siteA.example.com
REST API application:   http://siteB.example.com

поэтому мы используем CORS для реализации ресурсов из разных источников в веб-приложении. Это вводит несколько предварительных запросов OPTIONS, отправляемых браузером без заголовка ключа пользователя, таким образом получая ошибку HTTP 403 от 3scale.

Есть ли способ избежать такого поведения?

Источник

2 ответа

Если вы не можете обработать это на уровне приложения, тогда вы можете сделать оператор nginx if, чтобы обработать это.

location / {
    if ($request_method = OPTIONS ) {
        add_header Access-Control-Allow-Origin "http://example.com";
        add_header Access-Control-Allow-Methods "GET, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization";
        add_header Access-Control-Allow-Credentials "true";
        ...
        add_header Content-Length 0;
        add_header Content-Type text/plain;
        return 200;
    }
    ...
}

Через http://blog.rogeriopvl.com/archives/nginx-and-the-http-options-method/

Источник

У меня была такая же проблема в 3scale при использовании AWS AMI, и я смог ее решить, добавив app_key и app_id в разрешенные заголовки для запроса опций.

При тестировании запрос работал в почтальоне, но не работал через Chrome. В моем случае, когда браузер выполнил проверку опций предпечатной проверки, это привело к отклонению, потому что заголовки app_key и app_id по умолчанию не допускаются.

Добавление поддержки для этих заголовков может быть достигнуто путем добавления записи для них в конец заголовка "Access-Control-Allow-Headers". Я сделал эту конфигурацию отдельным файлом с именем cors.conf:

#### CORS ####
  if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Allow-Origin' '*';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,app_id,app_key';
    add_header 'Access-Control-Max-Age' 1728000;
    add_header 'Content-Type' 'text/plain charset=UTF-8';
    add_header 'Content-Length' 0;
    return 204;
  }
#### CORS END ####

Затем cors.conf был включен в любой блок "location /" в nginx.conf:

...
location / {
include /opt/openresty/nginx/conf/cors.conf;
  set $provider_key null;
  set $cached_key null;
...

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

Документ CORS для Nginx использовался в качестве базового уровня, и я отметил, что для получения желаемых результатов нужно было изменить только раздел OPTIONS.

Источник

Шлюз 3scale теперь поддерживает готовое определение политики CORS. Дополнительная информация здесь: https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.8/html/administering_the_api_gateway/apicast_policies

Источник

Если для переменной среды APICAST_PATH_ROUTING задано значение true, а APIcast предоставляет доступ к нескольким службам, если политика CORS не включена для всех служб, предварительный запрос OPTIONS получит ответ 403 (Запрещено).

Установите политику CORS для всех сервисов / API в вашем 3scale.

Дополнительная информация от RedHat:https://issues.jboss.org/browse/THREESCALE-3063

Источник
Другие вопросы по тегам