shiro（三）shiro实战——Spring 集成 Shiro(案例)
**步骤
加入 jar 包
配置 web.xml 文件
在 Spring 的配置文件中配置 Shiro**
配置 web.xml 文件
配置启动 Spring IOC 容器的 Filter
配置 WEB 应用中的 Shiro Filter
在 Spring 的配置文件中配置 Shiro
配置自定义 Realm：实现自定义认证和授权
配置 Shiro 实体类使用的缓存策略
配置 SecurityManager
配置保证 Shiro 内部 Bean 声明周期都得到执行的 Lifecycle Bean 后置处理器
配置AOP 式方法级权限检查
配置 Shiro Filter
配置 Shiro Filter
filterChainDefinitions 属性：设置 Shiro Filter 拦截的 URL 及访问该 URL 所需要的权限信息。
格式：URL_Ant_Path_Expression = Path_Specific_Filter_Chain。
等号左边是一个与 Web 应用程序上下文根目录相关的Ant 风格的路径表达式。
等号右边是逗号隔开的过滤器列表，用来执行匹配该路径的请求
Ant 风格资源地址支持 3 种匹配符：
?：匹配文件名中的一个字符
*：匹配文件名中的任意字符
**：** 匹配多层路径
路径表达式
URL 权限采取第一次匹配优先的方式
比如：
/account/** = ssl, authc
/account/signup = anon
如果传入的请求访问是 /account/signup/index.html，则会匹配 ssl, authc 权限，而 annon 将永不会被匹配！因为/account/** 匹配 短路 了其余的权限定义
权限信息
1、权限是用逗号隔开的过滤器列表，用来执行对该路径请求的匹配。
2、必须符合以下格式：filter1[optional_config1]， filter2[optional_config2]，…
filterN：一个 shiro 中的过滤器的别名
[optional_configN] ：可选的权限字符串。若该过滤器对该 URL 路径不需要特定的配置，可以忽略括号，于是 filteN[] 就变成了filterN.
shiro中默认的过滤器
authc 和 user
1、user 和 authc ：当应用开启了rememberMe 时，用户下次访问时是一个 user，但不是 authc，因为authc是需要重新认证的
2、user 表示用户不一定已通过认证，只要被 Shiro 记住过登录状态的用户就可以正常发起请求，比如rememberMe
3、简言之：以前的一个用户登录时开启了rememberMe，然后他关闭浏览器，下次再访问时他就是一个user，而不是authc
Remembered 和 Authenticated
Remembered(记住我)：
一个 记住我 的 Subject 不是匿名的，是有一个已知的身份ID(也就是subject.getPrincipals()是非空的)。即：这个被记住的身份 ID 是在之前的session 中被认证的。
如果 subject.isRemembered() 返回 true，则 Subject 被认为是被记住的。
Authenticated(已认证)：
一个已认证的 Subject 是指在当前 Session 中被成功地验证过：login方法被调用并且没有抛出异常
如果 subject.isAuthenticated()返回 true 则认为 Subject 已通过验证。
注意：Remembered 和Authenticated 是互斥的——若其中一个为真则另一个为假，反之亦然
filterChainDefinitions 案例
/admin=authc,roles[admin]：表示用户必需已通过认证，并拥有 admin 角色
/edit=authc,perms[admin:edit]：表示用户必需已通过认证，并拥有 admin:edit 权限
/home=user：表示用户不一定需要已经通过认证,只需要曾经被Shiro记住过登录状态
基于注解的授权
Shiro提供的注解
@RequiresAuthentication ：要求当前 Subject 已经在当前的session 中被验证通过才能被注解的类/实例/方法访问或调用。
@RequiresGuest ：要求当前的 Subject 是一个 “guest”，也就是他们必须是在之前的 session 中没有被验证或记住才能被注解的类/实例/方法访问或调用。
@RequiresPermissions：要求当前的 Subject 被允许一个或多个权限，以便执行注解的方法，比如：@RequiresPermissions(“account:create”)
@RequiresRoles：要求当前的 Subject 拥有所有指定的角色。如果他们没有，则该方法将不会被执行，而且 AuthorizationException 异常将会被抛出。比如：@RequiresRoles(“administrator”)
@RequiresUser：需要当前的Subject 是一个应用程序用户才能被注解的类/实例/方法访问或调用。要么是通过验证被确认，或者在之前session 中的 ‘RememberMe‘ 服务被记住。
基于标签库的授权：guest
guest 标签将显示它包含的内容，仅当当前的Subject 被认为是 guest 时。
guest 是指没有身份 ID 的任何 Subject：没有登录也没有在上一次的访问中被记住（RememberMe 服务）
guest 标签与user 标签逻辑相反。
例子：
Hi there! Please Login or Signuptoday!
基于标签库的授权：user
user 标签将显示它包含的内容，仅当当前的 Subject 被认为是 user 时。
User 在上下文中被定义为一个已知身份 ID 的 Subject，或是成功通过身份验证及通过 RememberMe 服务的。
该标签在语义上与authenticated 标签是不同的，authenticated 标签更为严格。
usre 标签与guest 标签逻辑相反。
基于标签库的授权
1、authenticated：当当前用户在当前会话中成功地通过了身份验证 authenticated 标签才会显示包含的内容。比 user 标签更为严格。在逻辑上与 notAuthenticated 标签相反。
2、notAuthenticated：当前 Subject 还没有在其当前会话中成功地通过验证，将会显示它所包含的内容
3、principal 标签将会输出Subject 的主体（标识属性）或主要的属性
4、hasRole 当当前Subject 被分配了具体的角色时显示它所包含的内容。hasRole 标签与lacksRole 标签逻辑相反。 例如：
Administer the system
5、lacksRole 标签：当当前Subject 未被分配具体的角色，显示它所包含的内容
6、hasAnyRole 标签：当前的 Subject 被分配了任意一个来自于逗号分隔的角色名列表中的具体角色，将会显示它所包含的内容。例如：
You are either a developer, project manager, or administrater.
7、hasPermission 标签：当前 Subject 拥有特定的权限时，会显示它所包含的内容。hasPermission 标签与 lacksPermission 标签逻辑相反。例如：
Create a new User
8、lacksPermission 标签：当前Subject 没有拥有（蕴含）特定的权限，将会显示它所包含的内容。也就是说，用户没有特定的能力。
密码加密
项目案例：https://pan.baidu.com/s/1mhIO1Pe