浪子

暂无

上一章我们讲了SecurityManager，接下来的章节顺序是根据SecurityManager的依次实现类的依赖组件来讲。在讲cacheManager前，我们先了解下Cache。Cache有效的存储临时对象来提升应用的性能。由于Cache不属于安全框架的核心功能，所以shiro本身并没有完全实现Cache机制。Cache接口相当于底层的缓存框架的顶层接口，shiro的一切的缓存操作都与这

SecurityManager 接口主要作用 为什么要先说SecurityManager呢？因为我觉得他是shiro的主要入口，几乎所有相关的权限操作，都由他代理了。 1.可以说是所有配置的入口，简化配置，方便使用。 2.一个接口就可以实现，验证的操作（登录、退出）、授权（授权访问指定资源、角色）、Session管理，相当于这些操作的门面（门面模式，也叫外观模式）。从上图我们可以看出Secur

Session是个状态性的数据上下文，可以理解为每个用户都有一个特定数据库，该数据库存储着每个用户自己的数据，在shiro里，它是和Subject绑定在一起的，通常用户通过Subject.getSession来获取使用。它在系统内会存活一段时间为用户提供客户端浏览器和应用服务器通讯的一些功能。以下是一些关于Session的使用场景。 1.用户登陆成功后，应用服务器产生个Session，且返回该S

Authenticator在shiro中是主要负责验证用户登录，它通常和一组Realm来协调、交互验证用户登录。一般情况下我们不会直接使用Authenticator。而是交由SecurityManager来委托使用。 1.Authenticatorpublic interface Authenticator { //根据用户输入的AuthenticationToken（账号密码）然后去和

Authorizer主要是执行授权操作,即访问资源的控制。在shiro里，authorizer通常不直接使用，而是配置在SecurityManager里，由SecurityManager委托调用。 AuthorizingRealm和ModularRealmAuthorizer 前面讲过一个AuthorizingRealm，它也实现了Authorizer的接口。 AuthorizingRealm

上一章我们讲完了CacheManager，我们这一章讲的是Realm. Realm是一个Security组件，它主要职责是通过各种手段（JDBC、hibernate、FILE IO..）从数据库（关系数据库、NOSQL、文件..）中访问应用程序的用户的验证信息（账户密码），授权信息（资源路径）。然后根据这些信息来操作用户的登陆验证操作，和访问资源文件的授权操作。 一般不直接实现该接口，而是继

SessionManager负责管理shiro自己封装的session的生命周期。 为什么shiro要自己封装session？ 1.可以为任意应用提供session支持，不依赖于底层容器 2.简单扩容session管理容器，可以实现任何数据源（redis，ehcache）来管理session，而不必担心jvm内存溢出 1.SessionManagerpublic interface Sess

Subject几乎代理了所有有关用户的Security的操作。如：验证、授权、session管理..，它也可以说是用户安全相关安全操作的门面。通常我们可以通过SecurityUtils.getSubject()来获取一个Subject。 我们知道在基于WEB的应用中，shiro在生成Session后，然后把SessionID保存在客户端浏览器的cookie value中。当请求再次过来时，根据c