看源码，重新审视Spring Security中的角色（roles）是怎么回事

标签：arch   arc   详细   数据   固定   prefix   code   都差不多   实现   

        follow me，我们继续往下刨根，看看hasAnyAuthorityName这个方法里面有些什么，注意上面代码中的调用hasAnyAuthorityName时，传递的参数，一个是

另外一个是

对应的都是一个实现方法。

从hasAnyAuthorityName这个方法中，我们可以知道，这是把传进去的一个或多个角色/权限，在登录用户具有的权限中进行查找

????????这里面的大家看到了吧，角色和权限是混合在一起进行鉴权的（题外话，大家看大神们写的代码，注意到其中的var5、var6、var4，这是搞什么？严重不符合命名规范啊）。
那么Spring Security是如何区分集合中的是权限、还是角色呢，我们继续抽丝剥茧，看看该方法中的getRoleWithDefaultPrefix(prefix, role)方法


看上面的代码清晰明了了吧，说明如下：
????????如果传进去的角色名称/权限名称为null，直接返回null；
????????如果传进去的角色名称/权限名称不为null，则判断defaultRolePrefix前缀这个参数是否为空和其长度，如果不为空，且长度不为0，则传进的参数为角色名称，那么继续判断其是否是以“ROLE”开始，如果不是，则在名称前添加前缀“ROLE”，并返回新的名称；
????????如果不是以上情况，即参数是权限名称或者带有“ROLE_”前缀的角色名称，直接返回传进去的字符串参数。

????????看了以上Spring Security的部分源码解析，我们可以得出什么结论呢（以角色、权限存放在数据库为例）：
????????1、原生的角色和权限并没有本质的区别，在鉴权时走的是完全相同的一个通道；
????????2、在进行权限控制时，角色可加可不加“ROLE”前缀，但在数据库中定义时，角色名称一定要添加“ROLE”前缀；
????????3、角色与权限之间并没有建立映射关系，角色是角色、权限是权限，这与我们实际应用中对角色的要求有很大出入；
????????4、实际应用中的角色被固化到代码中，也与实际要求不符，实际应用中，权限作为子节点可以写死，而角色作为全部或者部分权限的集合应该可以灵活调整；
????????5、不管是角色鉴权，还是权限鉴权，都只是以角色/权限的名称作为判断依据，所以权限的名称要唯一。
????????另外，从Spring Security的源码分析中可以发现，我们还可以通过RoleHierarchy进行角色的继承（默认admin登录只能访问/admin，访问不了/user；而user登录只能访问/user），但在实际项目中，最主要强调的是角色的灵活性，而不是继承性。
????????所以，对角色的管理、角色和权限的映射关系，都需要我们自己来实现。
????????好了，对Spring Security角色（roles）的分析就到此结束，从以上分析看，我们如果要把Spring Security应用于实际项目中，还需要做不少工作，至于如何简洁高效的利用Spring Security进行角色权限控制模块的开发，有兴趣的读者可以看我的视频介绍：https://edu.51cto.com/sd/091c7 ，希望对大家有有所帮助。

看源码，重新审视Spring Security中的角色（roles）是怎么回事

标签：arch   arc   详细   数据   固定   prefix   code   都差不多   实现   

原文地址：https://blog.51cto.com/3058076/2467692