Chrome 扩展 XHR 收到 403 响应,除非从 file:/// 启动
Chrome Extension XHR receives 403 response except when initiated from file:///
我正在开发一个 Chrome 扩展程序,它利用 fixer.io API 进行货币汇率计算。
我通过一个简单的 HTML 页面开发扩展,其中我通过 <script>
标签包含我的 JavaScript。当我想实时测试它时,我会构建它,转到 chrome://extensions
并单击 加载解压的扩展程序 。
每当我从简单的 HTML 开发页面向 API 发出请求时,一切正常。但是,当我构建我的扩展程序并通过内容脚本发出请求时,我收到了来自 API.
的 403 响应
马上,我要说我在 manifest.json:
中拥有这些权限
"permissions": [
"https://*/*",
"http://*/*"
]
这是我加载脚本的方式(根据 Makyen 的要求):
"content_scripts": [
{
"run_at": "document_start",
"css": [
"main.css"
],
"js": [
"script.js"
],
"matches": [
"file:///*",
"http://*/*",
"https://*/*"
]
}
]
如果我将请求更改为另一个(虚拟)API:
https://jsonplaceholder.typicode.com/posts?base=USD
一切正常,这意味着问题不在我的扩展设置中。
有问题的请求是这样的:
https://api.fixer.io/latest?base=USD
它给出了错误:
GET https://api.fixer.io/latest?base=USD 403 (Forbidden)
这是初始化请求的代码:
function currencyAPICall(currency, callback) {
var url = "https://api.fixer.io/latest?base=" + currency,
req = new XMLHttpRequest();
req.addEventListener("load", function () {
callback(data.rates);
});
req.open("GET", url, true);
req.send(null);
return req;
}
为了对此进行测试,我在开发 HTML 文件时将扩展名 运行 放在文件 URL 上。 IE。相同的代码 运行 两次,一次来自我的 HTML 页面,一次来自扩展。以下是结果:
除了使用 file
协议外,我的分机在任何地方都会收到 403。它是否在本地主机、Whosebug 甚至 fixer.io 网站本身上 运行 都没有关系。请求使用 https
.
求和
扩展内容脚本在任何地方都会收到来自 API 调用的 403 响应,除非 运行 在具有 file
协议的页面上,即使具有正确的清单权限。 为什么?
如果我向另一个 URL(前面提到的虚拟 API)发出请求,我不会收到此错误。这是否意味着问题出在 fixer.io 服务器上?或者我需要设置某种 header?
我还在 fixer.io 的 GitHub 回购中写了一篇关于此的 issue。
编辑:
我注意到的主要区别之一是 Origin
和 Referer
header。如果两者都已设置或均未设置,则响应似乎为 200。当我收到 403 响应时,Referer
已设置,但 Origin
未设置。
编辑:
根据 PredatorIWD 的建议,从 Event Page(又名后台页面)发出请求不会导致 403。我得到正常的 200 OK 响应。
正如我在评论中所说,从 background.js
发送请求并使用消息将所需数据发送回内容脚本通常更好。
这是从后台脚本到内容脚本的简单一次性消息示例:
来自后台脚本:
chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
chrome.tabs.sendMessage(tabs[0].id, {greeting: "hello"}, function(response) {
console.log(response.farewell);
});
});
到内容脚本:
chrome.runtime.onMessage.addListener( function(request, sender, sendResponse) {
if (request.greeting == "hello"){
sendResponse({farewell: "goodbye"});
}
});
您可以阅读有关消息传递的更多信息here。
我正在开发一个 Chrome 扩展程序,它利用 fixer.io API 进行货币汇率计算。
我通过一个简单的 HTML 页面开发扩展,其中我通过 <script>
标签包含我的 JavaScript。当我想实时测试它时,我会构建它,转到 chrome://extensions
并单击 加载解压的扩展程序 。
每当我从简单的 HTML 开发页面向 API 发出请求时,一切正常。但是,当我构建我的扩展程序并通过内容脚本发出请求时,我收到了来自 API.
的 403 响应马上,我要说我在 manifest.json:
中拥有这些权限"permissions": [
"https://*/*",
"http://*/*"
]
这是我加载脚本的方式(根据 Makyen 的要求):
"content_scripts": [
{
"run_at": "document_start",
"css": [
"main.css"
],
"js": [
"script.js"
],
"matches": [
"file:///*",
"http://*/*",
"https://*/*"
]
}
]
如果我将请求更改为另一个(虚拟)API:
https://jsonplaceholder.typicode.com/posts?base=USD
一切正常,这意味着问题不在我的扩展设置中。
有问题的请求是这样的:
https://api.fixer.io/latest?base=USD
它给出了错误:
GET https://api.fixer.io/latest?base=USD 403 (Forbidden)
这是初始化请求的代码:
function currencyAPICall(currency, callback) {
var url = "https://api.fixer.io/latest?base=" + currency,
req = new XMLHttpRequest();
req.addEventListener("load", function () {
callback(data.rates);
});
req.open("GET", url, true);
req.send(null);
return req;
}
为了对此进行测试,我在开发 HTML 文件时将扩展名 运行 放在文件 URL 上。 IE。相同的代码 运行 两次,一次来自我的 HTML 页面,一次来自扩展。以下是结果:
除了使用 file
协议外,我的分机在任何地方都会收到 403。它是否在本地主机、Whosebug 甚至 fixer.io 网站本身上 运行 都没有关系。请求使用 https
.
求和
扩展内容脚本在任何地方都会收到来自 API 调用的 403 响应,除非 运行 在具有 file
协议的页面上,即使具有正确的清单权限。 为什么?
如果我向另一个 URL(前面提到的虚拟 API)发出请求,我不会收到此错误。这是否意味着问题出在 fixer.io 服务器上?或者我需要设置某种 header?
我还在 fixer.io 的 GitHub 回购中写了一篇关于此的 issue。
编辑:
我注意到的主要区别之一是 Origin
和 Referer
header。如果两者都已设置或均未设置,则响应似乎为 200。当我收到 403 响应时,Referer
已设置,但 Origin
未设置。
编辑:
根据 PredatorIWD 的建议,从 Event Page(又名后台页面)发出请求不会导致 403。我得到正常的 200 OK 响应。
正如我在评论中所说,从 background.js
发送请求并使用消息将所需数据发送回内容脚本通常更好。
这是从后台脚本到内容脚本的简单一次性消息示例:
来自后台脚本:
chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
chrome.tabs.sendMessage(tabs[0].id, {greeting: "hello"}, function(response) {
console.log(response.farewell);
});
});
到内容脚本:
chrome.runtime.onMessage.addListener( function(request, sender, sendResponse) {
if (request.greeting == "hello"){
sendResponse({farewell: "goodbye"});
}
});
您可以阅读有关消息传递的更多信息here。