关于用户登录和权限验证功能的实现步骤（一）

本文转载自凌大大的博客，原博客地址：[关于用户登录和权限验证功能的实现步骤](https://blog.csdn.net/wohaqiyi/article/details/79322375)

本篇主要写shiro框架用于维护用户、角色、功能，在数据库中表的建立。

针对于shiro的应用，我们仅仅应用到用户登录和权限验证这两部分的功能，我后边的关于shiro的应用，也仅仅在这一层面上写。
shiro不会自己维护关于用户、角色、功能等的东西，在我理解，它保存的是一个叫subject的东西,而每一个登录系统的用户，都独属于一个subject，所有的这些subject统一被shiro的一个名字叫securityManager的东西来管理，具体如下：
这里写图片描述
上图我们先只关注subject和securityManager这俩东西的关系，其他的先不要管，后边的我会解释Realm。
通过上图，我们看到subject，会被securityManager来管理。除此之外，用户登录进来的会话，即session的一些特性，比如超时时间、cookie的别名，等等，也会通过sessionManager来统一集合，并且交付给securityManager来管理；还有realm,这个其实是用来个人实现用户验证、权限授权功能的一个东西，它也会被securityManager来管理，等等。总而言之，securityManger是shiro的指挥中心、心脏。

基本的介绍了，然后回到上边的红色部分，也就是shiro不会自己维护我们自己的用户角色功能的东西，我们需要持久化到数据库。这样就需要建表，也就是我们启用shiro框架的第一步，数据库表结构的建立。

1、数据库表结构的建立

用户表（SYS_USER）
用户角色关联表 (SYS_USER_ROLE_R)
角色表 (SYS_ROLE)
角色功能关联表 (SYS_FUNC_ROLE_R)
功能表 (SYS_FUNC)

要实现的用户登录和权限验证的功能，只需要这五张表即可以完成。所以这五张表是必须要建立的，通过表名来看，我们也能知道这五张表的意思是什么了。对于每张表的内容，最主要的如下：

用户表

用来记录用户用于登录的基本信息，比如用户名、密码，及用于忘记密码找回的邮箱或者电话。

 CREATE TABLE SYS_USER
   (USER_ID VARCHAR2(35) NOT NULL, 
    USER_NAME VARCHAR2(50),  //用户名 (不可重复，应该设为unique) 
    PASSWORD VARCHAR2(50),  //密码（存的是暗文）
    NICK_NAME VARCHAR2(100), //昵称
    EMAIL VARCHAR2(100), //邮箱 （主要用于密码找回，这个功能我没有做）
  )
    
    
     
     1
     
     2
     
     3
     
     4
     
     5
     
     6
     
     7

用户角色关联表

通过这个表，将用户表和角色表关联，可以实现一个用户对应多个角色的功能。

CREATE TABLE SYS_USER_ROLE_R 
(
  ID VARCHAR2(50) NOT NULL,
  ROLE_ID VARCHAR2(50),  //角色ID
  USER_ID VARCHAR2(50)  //用户ID
）
    
    
     
     1
     
     2
     
     3
     
     4
     
     5
     
     6

角色表

在我看来，用户拥有不同的角色，就会有不同的功能集，也就是说，不同的角色对应的不同的功能集，比如超级管理员角色和普通管理员角色的区别，肯定超级管理员拥有的权限会比普通管理员角色的多，这里说的权限，也就是功能，都是一个道理。

 CREATE TABLE SYS_ROLE
   (ROLE_ID VARCHAR2(32) NOT NULL,
    ROLE_NAME NVARCHAR2(40),  //角色名称
    CREATEUSER NVARCHAR2(20), //角色创建人（可有可无，我是一般加上）
    SITE_ID NUMBER(3,0) //站点名字
    )
    
    
     
     1
     
     2
     
     3
     
     4
     
     5
     
     6

上边的site_id ，假如你有多个系统，但是需要统一认证维护起来，假如你想让同一个用户登录多个系统，并且又要可配置，那用来区别系统的字段，绝对不能放到用户表，因为那样一个用户肯定只能配置一个系统，就写死了，所以必须放到角色表或者功能表，通过，给一个用户配置多个角色，这样的操作，实现一个用户拥有多个系统的角色。也可以将site_id 放到功能表，都是可以的。
关于siteId 放置的位置，我写了篇文章，可以看这个关于shiro框架中用户多站点登录的标识字段的位置。

角色功能关联表

通过该表，实现一个角色对应多个功能的关联。这里的功能就是权限。

CREATE TABLE SYS_FUNC_ROLE_R 
 (
    id varchar2(50),
    FUNC_ID VARCHAR2(50) , //功能表主键
    ROLE_ID VARCHAR2(50) //角色表主键 
 )
    
    
     
     1
     
     2
     
     3
     
     4
     
     5
     
     6

功能表

也就是权限表，记录的每一个权限，大到系统名称、模块名称、菜单项，小到一个按钮，都可以记录成一条功能表记录，我配置的系统，就有四种功能选项（系统、模块、菜单、操作），几乎把前端页面上的所有的东西都分类保存到了这个功能表里了。其实也就是记录了一个地址，后边会说到的。

CREATE TABLE SYS_FUNC 
(
  ID VARCHAR2(50) NOT NULL, 
  NAME VARCHAR2(100) ,  //功能名字
  FUNC_TYPE VARCHAR2(20) ,  //功能类别(系统、模块、菜单、操作)
  FUNC_URL VARCHAR2(200) , //功能URL
  PID VARCHAR2(50) ,  //功能父ID,用于构建树
  FUNC_SEQ NUMBER(10, 0) //排序，这个加上比较好，比如排序一下模块什么的
  SITE_ID NUMBER(3,0) //站点名字，功能表上最好也要有这个站点。
)
    
    
     
     1
     
     2
     
     3
     
     4
     
     5
     
     6
     
     7
     
     8
     
     9
     
     10

以上是数据库表的建立，后边的，基本就是通过这五张表来实现的全部功能。

下一篇先通过一个实现好的系统，结合sql来说一下如何做到的筛选。

下一篇链接地址shiro框架—关于用户登录和权限验证功能的实现步骤（二）