Spring中ContextLoaderListener的角色/目的?

将GrantedAuthority视为“权限”或“权利”。这些“权限”(通常)用字符串表示(使用getAuthority()方法)。这些字符串使你可以标识权限,并让你的选民决定他们是否授予对某些内容的访问权限。

你可以通过将用户置于安全上下文中来为其授予不同的GrantedAuthority(权限)。通常,你可以通过实现自己的UserDetailsS​​ervice来实现此目的,该服务返回一个UserDetails实现,该实现返回所需的GrantedAuthorities。

角色(在许多示例中使用过)只是“权限”,使用命名约定表示角色是以pre我正在学习在我的项目中使用的Spring Framework。我在web.xml文件中找到了 ContextLoaderListener条目。但是无法弄清楚它对开发人员有多大帮助吗?

在ContextLoaderListener的官方文档中,它表示要启动WebApplicationContext。关于WebApplicationContext JavaDocs说:

提供Web应用程序配置的界面。

但是我无法理解使用ContextLoaderListener实现内部初始化WebApplicationContext的目标吗?

据我了解,ContextLoaderListener 读取Spring配置文件(具有针对web.xml中的contextConfigLocation给出的值),对其进行解析并加载在该配置文件中定义的单例bean。类似地,当我们要加载原型bean时,我们将使用相同的Web应用程序上下文来加载它。因此,我们使用ContextLoaderListener初始化了Web应用程序,以便我们预先读取/解析/验证配置文件,并且每当我们要注入依赖项时,都可以立即进行操作而不会产生任何延迟。这种理解正确吗?fix开头的GrantedAuthority ROLE_。没什么了 一个角色就是一个GrantedAuthority-一个“权限”-一个“权利”。你会在Spring Security中看到很多地方,带有ROLE_前缀的角色是专门处理的,例如在RoleVoter中,ROLE_前缀被用作默认值。这样,你就可以提供角色名称而无需添加ROLE_前缀。在Spring安全4之前,这种对“角色”的特殊处理并未得到非常一致的遵循,并且权限和角色通常被视为相同(例如hasAuthority()hasRole())。使用Spring Security 4,角色的处理更加一致,处理“角色”的代码(如RoleVoter,hasRole表达式等)总是ROLE_为你添加前缀。所以hasAuthority('ROLE_ADMIN')指一样hasRole('ADMIN'),因为ROLE_前缀被自动添加。有关更多信息,请参见Spring Security 3到4 迁移指南。

但是,角色仍然只是带有特殊ROLE_前缀的授权机构。因此在Spring安全性3 @PreAuthorize("hasRole('ROLE_XYZ')")中与相同@PreAuthorize("hasAuthority('ROLE_XYZ')"),在Spring安全性4 @PreAuthorize("hasRole('XYZ')")中与相同@PreAuthorize("hasAuthority('ROLE_XYZ')")

关于你的用例:

用户具有角色,角色可以执行某些操作。

你可能最终会GrantedAuthorities获得用户所属的角色以及角色可以执行的操作。在GrantedAuthorities对角色有前缀ROLE_和操作都有前缀OP_。一个例子为业务主管部门可能是OP_DELETE_ACCOUNT,OP_CREATE_USER,OP_RUN_BATCH_JOB等角色可以是ROLE_ADMIN,ROLE_USER,ROLE_OWNER等。

你最终可能会GrantedAuthority像下面的(伪代码)示例中那样使你的实体实现:

@Entity

class Role implements GrantedAuthority {

@Id

private String id;

@ManyToMany

private final List<Operation> allowedOperations = new ArrayList<>();

@Override

public String getAuthority() {

return id;

}

public Collection<GrantedAuthority> getAllowedOperations() {

return allowedOperations;

}

}

@Entity

class User {

@Id

private String id;

@ManyToMany

private final List<Role> roles = new ArrayList<>();

public Collection<Role> getRoles() {

return roles;

}

}

@Entity

class Operation implements GrantedAuthority {

@Id

private String id;

@Override

public String getAuthority() {

return id;

}

}

你在数据库中创建的角色和操作的ID将是GrantedAuthority表示形式,例如ROLE_ADMIN,OP_DELETE_ACCOUNT等等。对用户进行身份验证时,请确保从UserDetails.getAuthorities()返回了其所有角色的所有GrantedAuthority和相应的操作方法。

例如:ID为admin角色ROLE_ADMIN有操作OP_DELETE_ACCOUNT,OP_READ_ACCOUNT,OP_RUN_BATCH_JOB分配给它。ID为的用户角色具有ROLE_USER操作OP_READ_ACCOUNT

如果造成安全上下文管理员日志将有GrantedAuthorities:ROLE_ADMIN,,OP_DELETE_ACCOUNTOP_READ_ACCOUNTOP_RUN_BATCH_JOB

如果一个用户登录它,它就会有: ROLE_USER,OP_READ_ACCOUNT

UserDetailsS​​ervice将注意收集所有角色以及这些角色的所有操作,并通过返回的UserDetails实例中的方法getAuthorities()使它们可用。

回答:

你的理解是正确的。该ApplicationContext是你的Spring beans住的地方。的目的ContextLoaderListener有两个:

  1. 将的生命ApplicationContext周期与ServletContext和的生命周期联系起来

  2. 可以自动创建ApplicationContext,因此你无需编写显式代码即可创建它-这是一项便捷功能。

关于的另一个方便之处ContextLoaderListener是,它创建了一个,WebApplicationContext并WebApplicationContext提供了对ServletContextvia ServletContextAwarebeangetServletContext方法的访问。

以上是 Spring中ContextLoaderListener的角色/目的? 的全部内容, 来源链接: utcz.com/qa/403594.html

回到顶部