不记名令牌过滤器是否应该避免 OPTIONS 请求？答案

【问题标题】：Should bearer token filter avoid OPTIONS request?不记名令牌过滤器是否应该避免 OPTIONS 请求？
【发布时间】：2017-08-30 00:57:16
【问题描述】：

我正在使用过滤器来检查授权持有者令牌是否有效。尽管如此，我仍然在为 user-agent(firefox, chrome...) 在发出“真实”请求之前尝试请求 CORS OPTIONS 请求而苦苦挣扎。

所以，我的过滤器拦截了这个 OPTIONS 请求，并且它没有任何授权承载令牌，因此它以 4xx http 代码进行响应。

我应该避免OPTIONS 请求吗？

private boolean isExcluded(ServletRequest request) {
    return ((HttpServletRequest)request).getMethod().equalsIgnoreCase(HttpMethod.OPTIONS);
}

在doFilter:

if (this.isExcluded(request))
    chain.doFilter(request, response);
else
    //...

这对吗？

【问题讨论】：

标签： jakarta-ee oauth-2.0 jax-rs

【解决方案1】：

任何 CORS 处理都应在任何身份验证之前完成。实现它的正确方法是在任何身份验证过滤器之前使用 CORS 过滤器。在 CORS 过滤器中，检查它是否是预检请求。如果是，则以 200 响应并设置 CORS 响应标头。然后从过滤器返回，因此没有进一步的处理。如果不是预检请求，则只需转到链中的下一个过滤器。

CORS 过滤器仅在响应端实现并让请求照常进行是不好的实现。例如，my post here 是一个非常糟糕的例子。这就是为什么我链接到RESTEasy CorsFilter 作为示例，说明它应该如何实现。

有关 CORS 预检的更多信息，请参阅 the MDN（如果您想了解它的工作原理，请务必阅读）。然后检查 RESTEasy CorsFilter 以了解它是如何正确实现的。尽管它使用了 JAX-RS 过滤器，但您可以获得一些使其与 servlet 过滤器一起工作的想法。需要注意的区别是 JAX-RS 过滤器分为两个过滤器（请求和响应），而 servlet 过滤器在过滤器上使用，您可以在其中预处理 -> 处理请求 -> 后处理。 JAX-RS 过滤器类似于预处理和后处理。

另请注意，OPTIONS 请求并不总是预检。您还应该检查 Origin 标头。

【讨论】：