有效的访问控制允许起源响应

Question

这类似于jquery ajax add身份验证标头，因为它与相同的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

这会导致错误：“ Access-Control-Allow-Origin”标头包含无效值“”，这表示不允许我的来源访问。

服务器为Access-Control-Allow-Origin标头返回一个空字符串（而不是我的来源或*）是否有效？ 如果那是有效的，我该如何正确验证我的请求？

Answer 1

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

W3建议以下内容

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

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的飞行前请求资源处理模型，此服务器行为会影响客户端行为。和您的浏览器。

在实际请求中已正确设置请求头中的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问题。