3scale的CORS

我們正試圖通過OpenShift設置一個3scale平臺來管理REST服務和JavaScript Web應用程序之間的API訪問。應使用放置在HTTP標頭中的用戶密鑰管理認證。兩個應用程序可到達不同的URL：3scale的CORS

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

所以我們用CORS對Web應用程序實現跨域資源。這引入了瀏覽器在沒有用戶密鑰頭部的情況下發送的幾個OPTIONS飛行前請求，因此從3scale接收到HTTP 403錯誤。

有沒有辦法避免這種行爲？

來源

2017-05-30 Giovanni Mancuso

如果你不能在應用程序級別處理它，那麼你可以做一個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/

來源

2017-05-30 14:57:50

我有同樣的問題在3比例使用AWS AMI時，並能夠通過添加APP_KEY解決它，並APP_ID爲期權請求允許的頭。

在測試在郵遞員工作的請求，但不會通過Chrome工作。在我的情況下，當瀏覽器發佈預檢選項時，檢查它會導致拒絕，因爲CORS默認設置不允許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被列入下的任何「位置/」塊在nginx.conf：

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

一旦這個改變使得我的瀏覽器能夠成功發出請求。

CORS on Nginx文檔被用作基準，我注意到只有OPTIONS部分需要修改才能得到想要的結果。

來源

2018-01-05 17:24:48 Melikoth

回答

相關問題