带有 Resteasy 的 JAX-RS：如何进行“超类”请求标头管理？ [复制]

Posted 2023-02-24

【中文标题】带有 Resteasy 的 JAX-RS：如何进行“超类”请求标头管理？ [复制]

【英文标题】：JAX-RS with Resteasy: How to do "superclass" request header management? [duplicate]

【发布时间】：2016-10-11 13:42:51

【问题描述】：

我处理的一个应用程序使用以下模式公开了各种 REST Web 服务：

@RequestScoped
@Path("/path")
public class SomeResource 

    @GET
    public SomeResponse get(
        @HeaderParam("authenticationHeader1") String authenticationHeader1,
        @HeaderParam("authenticationHeader2") String authenticationHeader2,

        @QueryParam("stuff") String stuff, 
        @QueryParam("moreStuff") String moreStuff)      
    
        final AuthenticationBean authBean = validateCredentials(authenticationHeader1, authenticationHeader2)

        if (!authBean.isValid()) 
            return someStronglyWordedResponse(authBean);
        
        else  
            return someProcessing(authBean, stuff, moreStuff);
        
    

这些身份验证标头的解析、验证和其他处理几乎适用于所有资源。

我可以创建一个抽象超类并在其中简单地定义validateCredentials()，因为AuthenticationBean 提取在任何地方都是相同的。

但这在 Java EE7 环境中让我觉得有点不雅，更重要的是，如果 Jimmy 在编码新资源时忘记添加身份验证管理怎么办？

是否有推荐的方法来解析所有请求的 HTTP 标头，无论目标资源如何，并对结果进行一些通用处理？

编辑：

此应用正在使用 Resteasy。很抱歉一开始没有提到它。我宁愿避免依赖于实现的解决方案，但 Resteasy 机制也是一种选择。

【问题讨论】：

重复链接接受的答案中提到的所有 API 都是标准的 JAX-RS 类。适用于任何实施。

@peeskillet 确实！很抱歉我快速重新打开编辑，我被重复的问题标题误导了。也许可以对其进行编辑以删除泽西岛参考？这就是让我首先跳过这个问题的原因。

【参考方案1】：

Jersey 为此提供了ContainerRequestFilter。他们有一个关于如何使用它们的很好的教程：https://jersey.java.net/documentation/latest/filters-and-interceptors.html

您可以只创建一个全局过滤器并在其中进行验证，如果失败，您可以使用requestContext.abortWith() 中止它，如示例 10.2 所示。可以轻松修改此示例以使用您的标头数据而不是安全上下文。可以使用requestContext.getHeaderString() 访问标头，标头名称作为唯一参数。

您还可以使用名称绑定（本教程中的 10.5）仅过滤对某些资源的请求。

【讨论】：

感谢您的回答@Leon。遗憾的是，该应用使用的是 Resteasy 而不是 Jersey，所以我将无法使用它......但是，如果我们切换实现，我会记住您的解决方案。

@SilverQuettier Jersey 链接中提到的过滤器和拦截器是标准的 JAX-RS 类。将适用于任何实现