Question

这与jquery ajax add authentication header类似，因为它与相同的API有关，但这更多是关于对OPTIONS请求的响应的有效值。

鉴于此：

$.ajax({
    url: "https://auspost.com.au/api/postcode/search.json?q=clayfield",
    headers: {
        'auth-key': '510839e3-****-****-****-6e04a56e9eb3'
    }
}, function (data) {
    var json = {
    json: JSON.stringify(data)
};
console.log(json);
});

我得到了这样的答复：

Access-Control-Allow-Headers:accept, auth-key
Access-Control-Allow-Methods:GET
Access-Control-Allow-Origin:
Access-Control-Max-Age:1200
Connection:keep-alive
Content-Length:0
Date:Fri, 13 Feb 2015 03:46:42 GMT
Server:nginx

出现错误：“访问控制 - 允许 - 来源”＃39;标头包含无效值＆＃39;＆＃39;这意味着我的来源不允许访问。

服务器是否有效为Access-Control-Allow-Origin标头返回空字符串（而不是我的原点或*）？如果有效 - 我如何才能正确认证我的请求？

Answer 1

“Access-Control-Allow-Origin”标头包含无效值，因为它在响应中为空。响应必须返回*或原始的指定ASCII文本。

W3建议如下

资源可以定义一个Access-Control-Allow-Origin标头。标头必须与以下ABNF匹配：

Access-Control-Allow-Origin =“Access-Control-Allow-Origin”“：”ascii-origin | “*”

请参阅：http://www.w3.org/TR/2008/WD-access-control-20080912/#access-control-allow-origin

正如其他人所建议的那样，服务器可以根据您提供的授权和来源正确返回这些值。也许如果您不尝试发送服务器值，服务器将不会返回无效响应。

**更新 - 2015年2月15日**

进一步挖掘后，我认为问题是服务器设置与目标服务器以及浏览器中的进程jquery / CORS组合。

在服务器级别似乎发生的情况是，如果AUTH-KEY不作为标头值出现，则服务器配置为在Access-Control-Allow-Origin响应头中返回空字符串。这不符合标准，但有些人选择此作为安全预防措施，以确保不会产生无效的CORS请求。

由于W3（http://www.w3.org/TR/cors/#preflight-request）定义的CORS的飞行前请求资源处理模型，此服务器行为会影响客户端行为，Jquery和您的浏览器会紧随其后。

在您在请求中正确设置AUTH-KEY的实际请求之前，生成预检请求作为OPTION请求（代替GET），以便让服务器有机会告诉您客户端CORS策略和身份验证是否允许处理请求。

标准还指定您提供的标头实际上并未在此预检请求中发送，而是转换为名为“Access-Control-Request-Headers”（http://www.w3.org/TR/cors/#http-access-control-request-headers）的单个标头值。对于通过jquery的特定请求，您将看到以下标题转换：

Access-Control-Request-Headers: accept, auth-key

由于auth-key未传递给服务器，并且如上所述，您的服务器不会向OPTION请求返回“有效”响应，因为此OPTION请求不包含您的实际AUTH-KEY标头但是而是Access-Control-Request-Headers标头，这是一个空的Access-Control-Response-Headers响应，在处理XMLHttpRequest时会生成浏览器错误。

作为一种解决方案，我会尝试在您首选的服务器端页面（PHP，.NET，无论如何）中设置本地服务器页面，该页面将执行简单的服务器到服务器请求，然后使用您的ajax请求您的本地服务器页面代理可以解决上述CORS问题。

有效的Access-Control-Allow-Origin响应

1 个答案: