Grails CORS 未启用，因为没有来源答案

【问题标题】：Grails CORS not enabled because no originGrails CORS 未启用，因为没有来源
【发布时间】：2016-11-01 09:39:02
【问题描述】：

我有一个 grails 2.2.4 应用程序。我想启用 CORS 所以我通过在构建配置中添加以下行来安装 cors 插件。

plugins {
    runtime ':cors:1.1.8'
}

然后在config.groovy中

cors.headers = ['Access-Control-Allow-Origin': '*']

但在此之后，当我运行应用程序时，CORS in 未启用。所以我调试了CORS插件。问题似乎在以下方法中的 CorsFilter 类中

private boolean checkOrigin(HttpServletRequest req, HttpServletResponse resp) {
    String origin = req.getHeader("Origin");
    if (origin == null) {
        //no origin; per W3C spec, terminate further processing for both preflight and actual requests
        return false;
    }

上一行中的 origin 参数始终为 null，因为请求没有参数 'Origin'。有什么我做错了吗？我不是在寻找添加一个名为“Origin”的手动标题的答案，因为这不是一个正确的修复

我对 CORS 还很陌生，因此请多多指教。

【问题讨论】：

您的设置有问题。如果要相信developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin（并且可能应该），那么每个 CORS 请求都应该包含“Origin”HTTP 标头。在您的测试场景中生成请求的原因是什么？
为了测试，我使用 RestClient 发送请求，在标头中设置内容类型并将 GET 请求发送到我的本地主机和开发服务器。如果我向服务器发送请求，则使用相同的 RestClient 手动将 Apache cors.conf 中的 CORS 设置更改为 Access-Control-Allow-Origin': * 我在启用所有来源的响应中返回标头。（因为我有负载平衡，新的启动服务器获得默认值，无论如何我想通过插件处理这个）
在这种情况下，RestClient 看起来不像是浏览器：我在它的代码中找不到任何暗示它自己向任何请求添加“Origin”标头的内容。正如您在上面的 mozilla 链接中看到的那样，真正的浏览器可以做到这一点。所以看起来你需要的答案是你明确表示你不想要的答案......至少，你应该只需要通过在 RestClient 实例上调用 setHeaders([Origin: 'http://idontthinkitmatters/']) 来做一次。

标签： grails groovy cors

【解决方案1】：

除了 Access-Control-Allow-Origin 之外，除了根据请求设置 Origin 标头之外，您可能还需要指定这些响应标头：

访问控制允许标头：接受
访问控制允许标头：来源
访问控制允许标头：内容类型
访问控制允许方法：GET
访问控制允许方法：POST

还要确保使用这些标头和空白的 200 OK 响应响应 HTTP OPTIONS 请求。

【讨论】：

我尝试了以下方法，但仍然遇到同样的问题。 ` "Access-Control-Allow-Origin": "", "Access-Control-Allow-Methods":"POST, PUT, GET, OPTIONS, PATCH", "Access-Control-Allow-Headers":" ", "Access-Control-Allow-Credentials":"true"` 也许老师的评论是正确的，唯一的解决方案是添加带有来源的标头。
Access-Control-Allow-Headers & Access-Control-Allow-Origin 的值为 *，我无法直接将它们作为评论添加到“
通配符应该适用于来源，但逗号分隔的列表不适用于 Access-Control-Allow-Methods，我相信您需要重复标题。使用 Access-Control-Allow-Headers 您需要指定标头，我认为通配符不起作用。

【解决方案2】：

现在，让我们假设 RestClient 正在正确发送 Origin 标头。它可能仍会被您的应用程序剥离。您可以使用 Access-Control-Allow-Headers: Origin 标头来防止这种情况发生。

我的 Web 服务遇到的大多数问题是发送了正确的标头，但我的 Web 服务器从消息中删除了它们。所以我倾向于采用“允许一切”的霰弹枪方法，然后将我不需要的东西一个一个删除。我的 allow-headers 标头通常很长，我最终不得不在我的请求最终通过之前包含诸如 Content-Type, X-Requested-With 和其他垃圾之类的东西。

我进一步建议您使用 RestClient 之外的其他东西进行测试，如果只是作为健全性检查。我使用免费的 Chrome 应用程序 Postman 进行所有消息传递测试。在我看来，问题在于 RestClient 没有发送正确的 Origin 标头。

【讨论】：

我尝试了以下方法，但我仍然遇到同样的问题。 ` "Access-Control-Allow-Origin": "", "Access-Control-Allow-Methods":"POST, PUT, GET, OPTIONS, PATCH", "Access-Control-Allow-Headers":"", " Access-Control-Allow-Credentials":"true"` 也许老师的评论是正确的，唯一的解决方案是添加带有来源的标头。仅供参考：我也尝试过 chrome postman，没有区别。
您刚才在评论中发布的某些标题似乎是空白的。除非他们有价值观，否则他们不会做任何好事。例如，我已经指出的 Access-Control-Allow-Headers 在您刚刚尝试的内容中是空白的。如果它是空白的，则意味着它可能会拒绝某些标头，包括 Origin。
对不起，它们的值是 * 但由于某种原因它没有被添加为评论。
我可能错了，但我认为 * 仅适用于 Allow-Origin。我认为对于标题和方法，您必须专门列出您想要允许的每一个。至少，尝试在 Allow-Headers 中专门列出 Origin，看看是否有任何改变。如果您仍然无法使其工作，则可能值得添加 Origin 标头本身，而不是作为永久解决方案，而只是为了验证它确实解决了问题。如果它不能解决问题，则表明存在不同的问题。