私はここでは非常に新しいユーザーで、私がルールを壊したらすぐに謝罪します。これが私が直面している問題であり、提案が必要です。
私はa Chrome拡張機能を持っています.Gmailと連携して、Phunx上で実行されている私のWebサーバーからPhusion Passenger Server of Railsアプリケーションを介してAPIを消費します。
My NginxバージョンはNGINXバージョンです.NGINX/1.15.8とPhusion Passengerバージョンは、Phusion Passenger Enterprise 6.0.1です。
次のようにNginxにCORS設定がありました。
_####### CORS Management ##########
add_header 'Access-Control-Allow-Origin' 'https://mail.google.com,https://*.gmail.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE, HEAD';
add_header Referrer-Policy "no-referrer";
add_header Pragma "no-cache";
##################################
_
これはChrome 84まで働くために使用されますが、Chrome 85の最新のアップデートで、次のようにCORSエラーを投げる開始しました。
########### = in Chrome 85 #############
Origin 'https://mail.google.com'からの 'https://my-site.com/jp'のフェッチへのアクセスは、CORSポリシーによってブロックされています。要求されたリソース.
############################################
その後、私はさまざまなソースやブログからの提案/参照に従って、CORS設定を広く開くまで更新し、更新されたCORS設定は次のようになります。
_
location / {
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' $http_Origin always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
#
# Custom headers and headers various browsers *should* be OK with but aren't
#
add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type' always;
#
# Tell client that this pre-flight info is valid for 20 days
#
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain charset=UTF-8' always;
add_header 'Content-Length' 0 always;
return 204;
}
if ($request_method = 'POST') {
add_header 'Access-Control-Allow-Origin' $http_Origin always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type' always;
}
if ($request_method = 'GET') {
add_header 'Access-Control-Allow-Origin' $http_Origin always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type' always;
}
}
_
###############################################
この設定をNGINXで更新した後、CORSエラーは発生しましたが、拡張機能がAPI呼び出しを行ったときにサーバーから401の不正なエラーを取得しています。
私はすべてのメソッドを微調整しようとしましたが、それを修正することができませんでした。私が行方不明のものや違ったことをしていることはありますか?
助けてください!
私は同じ問題を抱えていました。 HTTP要求をBackground Content Scriptに移動するための私の解決策は(上のリンクに記載されているように)。バックグラウンドスクリプトにメッセージを送信してそこから要求を実行する必要があります。
応答を受信するには、応答データを処理できるコンテンツスクリプトにメッセージを送信する必要があります。
ContentPage BackgorundPage
-- RequestData -->
Initialize the request and return to the content script
.... some time later....
Callback of HttpRequest is finished
<-- handleResponse-- (In callback handler)
_
コンテンツスクリプト:
var msg = new Object();
msg.message = "loadOrders";
chrome.runtime.sendMessage(msg);
_
背景 - スクリプト:
chrome.runtime.onMessage.addListener(
function (msg, sender, sendResponse) {
if( msgName=="loadOrders") {
doXHRRequest( function(responseData) {
sendMessageToActiveTab(responseData);
});
}
function sendMessageToActiveTab(responseData) {
var msg = new Object();
msg.message = "receiveOrders";
msg.orderList = JSON.parse(Http.responseText);
chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
chrome.tabs.sendMessage(tabs[0].id, msg);
});
}
_
コンテンツスクリプトで最後に:
chrome.runtime.onMessage.addListener(function(message, callback) {
if( message.message == "receiveOrders") {
receiveOrderList(message.orderList);
}
return;
});
_
述べられているように https://developers.google.com/web/updates/2020/07/chrome-85-deps-rems
chromeは安全でないSamesite = None Cookiesを拒否します
SAMESTES SETを使用したCookieの使用secure属性がないと、サポートされていません。 samesite = noneを要求するが、安全でマークされていないCookieは拒否されます。この機能は、2020年7月14日に安定したChromeのユーザーに転がり始めました。フルタイムラインと詳細についてSamesiteのアップデートを参照してください。プレーンテキストチャンネルを介して配信されたクッキーは、ネットワーク攻撃者によってカタログ化または変更されてもよい。クロスサイトの使用を意図したクッキーのための安全な輸送を要求すると、このリスクが軽減されます。