标签：授课 角色 Spring 用户 role 权限 id Shiro
Spring整合Shiro 权限 角色 用户关系分析
作者 ： Stanley 罗昊
【转载请注明出处和署名，谢谢！】
前置内容
之前我们学习了，使用注解的方式去完成权限的控制，当然，也是静态的，也就是说我们之前并没有与数据库交互；
所以，接下来就是，如果我们要依靠数据库来实现授权，说白了就是需要去数据库查找该用户是否拥有这项权限；
所以，这里我们可以想一下，既然已经用到数据库了，我们就可以联想到在数据库中，是不是有一个字段来专门保存权限呀；
这个时候，我们就需要想一个问题了，我们该如何去设计或创建这张表呢？
在这里，我们的用户、角色、权限，他们之间都是怎么关系呢？
所以，在数据库中，我们就依赖这三者关系所建立出来的；
所以，这个时候我们需要缕清，用户、角色以及授权这三者究竟是什么关系；
用户、角色及授权三者关系
Shiro的授权模式采用Rbac模式，意思就是，谁，扮演了什么角色，被允许执行什么操作，其中的“谁”就是user，其中扮演什么角色（role），操作就是权限（permission）；
接下来，我们来看一幅图，并作出详细解释：
可操作的事情、所处角色、具体实施的人；
我们来看，他们之间的关系对应的是什么？
首先我们来看可操作的事情：
我们在这个栏中可以看到，我们分别有 主持班会 授课 课间辅导 ...；而它对应上的中间的这一栏，也就是所处职位。
分别有授课老师，班主任以及校长；再往后呢，会对应上我们具体实施的人，dafei（大飞）laow（老王）stef（斯特芬）；
我们先来看左边两个，比如中间栏中的授课老师，它分别对应上了授课、课间辅导、课程设计；对应我们的班主任呢，它就可以主持班会主持研讨会；
大家注意看，这个是不是就是仅仅职位所能干的事情呀，也就是说这某一个职位所具有的职能被允许做某些事情；
这个时候，左面这两个栏中，跟用户（右一）这一栏中，有任何关系吗？
答案是没有关系，那么在什么时候有关系呢？比如这个时候，dafei出来了，如果它被任命为授课老师的话，拿换一句话说，这个dafei是不是就已经拥有授课课间辅导以及课程设计的权力了呀；
角色有许多种，所以，不同的角色可以执行不同的操作；
而具体实施的人，就是我们的用户，用户扮演某种角色，如果这个用户扮演了校长这个角色，那么它就被授予校长所拥有的操作，正如上面栏目中的授课及主持研讨会；
三者之间存在的关系
所处的职位与可操作的事情之间有什么关系吗？
首先看授课，授课老师是不是可以做三件事情，授课、课间辅导、设计课程，那么反过来，是不是可执行操作能对应上许多职位呀，比如授课可以给校长，也可以给班主任；所以他们之间的关系是多对多对多关系；
一个权限，可以分配给多个角色，一个角色可以拥有多个权限，也是一样的说法；
角色跟用户又是什么关系呢？
我们先来站在stef的角度来看，他是不是即可以担任校长又可以授课，也就是他拥有两个角色；
反过来说呢，角色也可以给多个用户进行扮演，所以他们之间也是多对多的关系；
用户跟权限有关系吗？
是没有关系的！他们之间是没有直接的关联，如果非要扯上关系的话，那么就需要通过中间的这个角色；
比如，这个dafei对应上我们的授课老师，所以大飞就拥有了授课、课程辅导、课程设计这三种权限；
所以，角色是他们俩之间的关联，使他们拥有了关系；
数据库表的设计
我们需要把他们分成三张表进行设计：
权限表 角色表 用户表，这三张表；
但是，你们这三张表相互独立，是无法体现出多于多的关系；
那我们该怎么办呢？
如果想产生多与多多对多的关系，那么就必须借助中间表；
所以需要五张表：
permission权限表 role角色表，role_permission权限角色关联表：
这个是他们俩的中间关联表；说白了就是role是角色表，他所对应的权限，比如role表中的id1是校长这个时候permission表中id1 与 id3是校长所拥有的操作，主持研讨会与授课，所在中间表里体现的就是：
role_id permission_id
1 1
1 3
接下来呢，就是用户与角色的对应；用户与角色也是多对多的关系；
所以就存在一个用户与角色之间的关联表：
你这个用户，扮演了什么角色，角色也可以被多个用户扮演；比如：userid1 name是小明 userid2是小刚；roleid1所属角色是校长；id2是教师；
user_id role_id
1(小明) 1（扮演校长）
2（小刚） 2（扮演教师）
如果用户是扮演了两个角色呢？很简单；假设 userid15 是大飞 他拥有 校长与授课老师的角色 校长角色 roleid对应5 教师对应 3
user_id role_id
15(大飞) 5（扮演校长）
15(大飞） 3（扮演教师）
数据库字段设计
用户表：
用户表就比较简单【讲解模式下】：
不需要在该表中关联任何权限之类的，因为在另外两张表中已经规划好；
角色表：
角色表也非常简单，第一个是id，第二个就是name角色名称的意思，第三个就是对应的英文标识，用英文诠释name中的中文，仅此而已；
换成上面图片中的内容，就是授课老师 班主任 校长...这些可扮演的角色；
权限表（可操作的事情）：
权限表就非常重要了！
权限就是表示我们可操作的事情；前面的id就是权限id中间的name就是权限的名称，比如主持班会 授课 课程设计，而后面这个呢，就是权限表达式，也是最关键的一个，就是由它来控制权限的；
在Shiro中，权限表达式是按照三段式来写的，第一段前面是资源中间一个双点（ ：）然后再双点后面跟上资源实例；
所以，在字段中，resource就是资源表达式，我们需要把一段权限表达式写在该字段内；
就如上面写的一样，把选中的部分放入到字段中；
role与permission中间表（角色与权限中间表）：
这个我在上方也详细说过；
role_id：
这个字段存的是role表中的id，就是角色表id，这个角色可以拥有那些权限（permission_id）;
permission_id
这个字段是权限表，也就是可以操作的事情，代表这个角色可以拥有那些权限，并产生多对多的关系；
一个角色(role_id)可以被授予多个权限（permission_id）;反过来，一个权限可以被多个角色使用；
用户表（user）：
用户表就无需添加任何字段，因为，另外四张表都使用了用户表的ID，所以产生了被动牵连；
用户(user)与角色(role)关系表
user_id就是用户表中用户的id，role_id就是角色表中的角色id；
意思就是，这个用户可以扮演某些角色，一个用户可以扮演多个角色；
一个角色也可以被多个用户同时扮演；
标签：授课,角色,Spring,用户,role,权限,id,Shiro 来源： https://www.cnblogs.com/StanleyBlogs/p/12040485.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。