我正在开发一个与Heroku API交互的Chrome扩展，但使用XMLHttpRequest(XHR)发出的请求似乎不像curl那样处理。特别是，基本身份验证似乎没有与XHR一起使用，而是与cookie一起使用。
因此，如果我运行以下程序：
curl https://:yourapitokengoeshere@api.heroku.com/user -H "Accept: application/json"
我毫无问题地得到了正确的结果。
另一方面，如果我在Chrome JavaScript控制台中为我的扩展页面运行以下操作，请求的成功与否将取决于我是否登录到Heroku。
var xhr = new XMLHttpRequest()
xhr.open("GET", "https://api.heroku.com/user", false, "", "yourapitokengoeshere")
xhr.setRequestHeader("Accept", "application/json")
xhr.send()
如果我登录了，我会得到与xhr.responseText中的curl相同的结果。如果我已注销，我将获得GET https://:yourapitokengoeshere@api.heroku.com/user 401 (Unauthorized)。我可以从网络选项卡中看到，Cookie是传递的，Heroku的响应基于此，而不是XMLHttpRequest::open中作为传递密码传递的API令牌。(我也尝试在不使用用户名和密码参数的情况下打开https://:yourapitokengoeshere@api.heroku.com/user，结果相同(如预期，但值得尝试))
如果你想尝试一下，我的manifest.json就是：
{
"name": "Testing Heroku.js",
"version": "0.1",
"background": {
"page": "test.html"
},
"permissions": [
"cookies",
"https://api.heroku.com/"
],
"manifest_version": 2
}
test.html只是一个空文件，因此我可以打开检查视图并访问扩展上下文中的控制台。在任意位置创建这两个文件，并将封闭目录作为未打包的扩展名加载。
所以我的问题是：对此我能做些什么吗？我是不是错过了什么？API Heroku有什么问题吗？还是XMLHttpRequest？我倾向于API的不端行为…
更一般地说，我有兴趣了解XMLHttpRequest调用和curl调用之间的区别。
根据我的研究，如果没有cookie，我似乎无法使用XMLHttpRequest，也无法更改用户代理使其看起来像curl。我还尝试了一些方法使curl的行为类似于XMLHttpRequest(更改用户代理，使用相同的头)，但curl总是按预期工作。
谢谢！
您需要生成一个Heroku密钥，如下所示：
herokuKey = btoa(":" + herokuToken + "n")
然后用适当的标题提出请求。
xhr = new XMLHttpRequest()
xhr.open("GET", "https://api.heroku.com/apps")
xhr.setRequestHeader("Accept", "application/vnd.heroku+json; version=3")
xhr.setRequestHeader("Authorization", herokuKey)
xhr.send()
我从这篇文章中拼凑出来：https://devcenter.heroku.com/articles/platform-api-quickstart并使用您的示例使其适应网络。
Heroku支持团队的回答：
这就是Rails的怪异之处。直到最近，API还处理web UI等，因此在这种情况下，假设XHR不是API请求，而是来自API网站上最终用户的请求是正常的。
希望在不久的将来，我们的API不会再与这种行为捆绑在一起，也会被宣布为一个合适的产品(带有合适的文档)。
所以，问题出在API上。