私は"*://*/*"
の権限を持つGoogle Chrome拡張機能にあり、XMLHttpRequestからFetch APIに切り替えるようにしています。Fetch APIで応答ヘッダーを読み取る
エクステンションは、HTTP認証のXHRのopen()呼び出しに直接使用されていたユーザー入力ログインデータを格納しますが、フェッチの下で直接パラメータとして直接使用することはできません。手動Authorizationヘッダを設定することができるようにHTTP基本認証のために、この制限を回避することは、自明である。
fetch(url, {
headers: new Headers({ 'Authorization': 'Basic ' + btoa(login + ':' + pass) })
} });
HTTP Digest Authしかし、より双方向性を必要とします。有効な認可トークンを作成するためにサーバーが401応答であなたに送るパラメーターを読み取る必要があります。私はこのスニペットをWWW-Authenticate
レスポンスヘッダフィールドを読んで試してみた:
fetch(url).then(function(resp) {
resp.headers.forEach(function(val, key) { console.log(key + ' -> ' + val); });
}
しかし、私が得るすべては、この出力されます。
content-type -> text/html; charset=iso-8859-1
自体が正しいですが、それはまだ約6つの複数のフィールド欠けていますChromeの開発ツールによるとresp.headers.get("WWW-Authenticate")
(または他のフィールドを使用している場合)は、null
となります。
Fetch APIを使用して他のフィールドにアクセスする可能性はありますか?
@jules CORSのこの制限は、 'access-control-expose-headers'または' access-control-allow-headers'の値を尊重します。 – jacob
'access-control-expose-headers'はサーバから返されたヘッダのために働いていました - ヘッダはフェッチレスポンスのヘッダオブジェクトを介して利用できます。そして、 'access-control-allow-headers'がサーバ上のリクエストヘッダを許可するために使われました。(または私はサーバからエラーメッセージを受け取るでしょう) – specimen
これはFetchでは不可能ですが、XmlHttpRequestで行うことができます。回避策がある場合でもセキュリティ上の利点は何ですか? – sebas