gpt4 book ai didi

java - @RolesAllowed 在 Jersey 资源上总是被拒绝(禁止)

转载 作者:塔克拉玛干 更新时间:2023-11-01 21:56:39 26 4
gpt4 key购买 nike

我正在尝试根据我通过 Jersey/JAX-RS 公开的资源的角色设置身份验证。此资源存在于 Glassfish 实例中,其中基于角色的身份验证(具体而言,通过 @RolesAllowed)当前正在按需要工作。我在 servlet 容器中运行 Jersey:

    <servlet-class>
com.sun.jersey.spi.container.servlet.ServletContainer
</servlet-class>

并且正在对我的资源强制执行基本身份验证;该要求正在按预期执行。我还向 Jersey 提供了以下初始化参数:

    <init-param>
<param-name>com.sun.jersey.spi.container.ResourceFilters</param-name>
<param-value>com.sun.jersey.api.container.filter.RolesAllowedResourceFilterFactory</param-value>
</init-param>

但是,当我尝试实际添加 @RolesAllowed 注释时,所有访问都失败了。例如:

@Path("/my/resource")
@ManagedBean
@RolesAllowed({"SYSTEM"})
public class Resource {
// Accesses with credentials for a user that has the SYSTEM role fail!
}

如果我注入(inject)一个安全上下文并调用 context.isUserInRole(),它会为所有角色返回 false。非常奇怪的是,如果我删除此资源的 @RolesAllowed 注释,并使用有效凭据发出请求,则此类可以成功访问 EJB,这需要用户处于我最初尝试测试的相同角色。看起来 Jersey 可能正在使用错误的 SecurityContext 或类似的东西进行身份验证。有没有其他人遇到过这种情况?

最佳答案

this 的一行之前,我在类似问题上挣扎了几个小时IBM 的文章让我大开眼界。令人惊讶的是,没有一本书或用户指南提到这个关键事实,否则身份验证就无法成功。

当使用基于注释的安全性时,web.xml 不是可选的;恰恰相反,<security-constraint>元素必须存在; Web 容器在 JAX-RS 之前检查安全性并且没有 <security-constraint> ,未设置适当的安全上下文。因此,当 JAX-RS 调用 isUserInRole(role) 时, 它总是返回 false。

此外,<security-role> web.xml 或 @DeclareRoles 中的元素注释必须存在。

最后,如果使用 Jersey,RolesAllowedDynamicFeature需要在 Application 类中注册以启用基于注释的安全性。

HTH 其他人在与可悲的文档作斗争,或者缺乏文档,那是在那里。

关于java - @RolesAllowed 在 Jersey 资源上总是被拒绝(禁止),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19060865/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com