zoukankan      html  css  js  c++  java
  • Session(数据)共享的前后端分离Shiro实战

    1,前言
         本文期望描述如何使用Shiro构建基本的安全登录和权限验证。本文实战场景有如下特殊需求:1,在集群和分布式环境实现session共享;2,前端只使用HTML/CSS/JS。因此无法直接使用Shiro提供的SessionManager,以及Shiro针对web应用提供的Filter拦截方式。当然,除非是一定要通过共享缓存的方式共享session,否则还是使用Shiro默认的session管理,毕竟增加独立缓存就意味着维护成本的提高和可用性的下降。
     
    2, Shiro架构
         首先一睹官方给出的Shiro架构图,如图1所示。刨除最右侧的加密工具类,主要围绕SercurityManager来阐述。SercurityManager是Shiro安全框架里的顶层安全管理中心,所有安全控制相关逻辑都是在SercurityManager里面通过delegate的方式,调用到真正的动作执行者。从图1可以清楚看到主要管理的组件:authentication管理,authorization管理,session管理,session缓存管理,cache管理,realms管理。(本文不想重复已有的文字,想要更好的了解Shiro,详见官方推荐的Shiro full intro: https://www.infoq.com/articles/apache-shiro)
         1)Shiro提供的CacheManager比较单薄,提供实现是MemoryConstrainedCacheManager,主要是依赖SoftHashMap来做基于内存条件的缓存,也即是当内存吃紧,没有新的内存空间来存放new出来的对象时,会去释放SoftHashMap中存放的对象,在本文中的应用场景是面向集群和分布式应用环境,使用了Redi缓存登录用户的相关信息,所以需要自定义cache处理。
         2)Shiro对于session的缓存管理,定义了SessionDAO抽象,并提供了两个存放于本地JVM内存的EnterpriseCacheSessionDAO和MemorySessionDAO,两者主要区别是EnterpriseCacheSessionDAO的session存放在SoftHashMap中,原则上可以自己实现SessionDAO 接口,实际存储使用Redis来做到完整的session共享,但是缺陷是:a,不安全,因为把所有数据都共享出去了;b,当每次需要获取session数据时,都需要通过网络来把整个session反序列化回来,而考虑很多情况下,只是间断的需要几个key的数据,这样在session数据量大一些的时候,就会产生大量消耗。因此在共享session时,不去替换默认SessionDao的实现,而是通过@overwrite AbstractNativeSessionManager getter/setter attribute方法,实现有选择的共享session的基本初始化和指定attribute key的数据。
         3)Shiro的authentication和authorization过程主要是依据用户定义的 AuthorizingRealm中提供的AuthenticationInfo和AuthorizationInfo。特别地,authentication 还提供类似验证链的authentication策略,允许用户提供多个Realm。第3部分会具体的示例Shiro集成Spring的使用范例,并详细解释AuthorizingRealm 。
     
    图 1 Shiro官方架构图
    3, Shiro使用范例
         官方提供了集成Spring Web应用的使用例子,但是就如前文提到的,这里前端只能使用JS的Http和后端通信,因此无法直接使用ShiroFilterFactoryBean来做Request的Filter。本文鉴于简单和初期的原则,可以选择定义一个RequestInterceptor类继承HandlerInterceptorAdapter并overwrite preHandle 方法。Interceptor的applicationContext和源码定义如下:
     
    applicationContext.xml
     1 <mvc:interceptors>
     2     <mvc:interceptor>
     3         <mvc:mapping path="/**"/>
     4         <!--拦截的url -->
     5         <mvc:mapping path="/admin/**"/>
     6         <!-- 不拦截的url start -->
     7         <mvc:exclude-mapping path="/admin/login"/>
     8         <mvc:exclude-mapping path="/admin/code"/>
     9         <mvc:exclude-mapping path="/admin/logout"/>
    10         <mvc:exclude-mapping path="/admin/msgErrorInfo"/>
    11         <!--不拦截的url end -->
    12         <bean class="authorizing.RequestInterceptor">
    13             <property name="unauthenticatedUrl" value="/admin/msgErrorInfo" />
    14         </bean>
    15     </mvc:interceptor>
    16 </mvc:interceptors>
     
    RequestInterceptor.java
     1 public class RequestInterceptor extends HandlerInterceptorAdapter {
     2  
     3     private String unauthenticatedUrl;
     4  
     5     public boolean preHandle(HttpServletRequest request, HttpServletResponse response,
     6             Object handler) throws Exception {
     7         if(PermissionUtils.isLogin(request)){
     8             return true;
     9         }
    10         //token已失效,返回提示信息
    11         request.getRequestDispatcher(unauthenticatedUrl).forward(request, response);
    12         return false;
    13     }
    14  
    15     public void setUnauthenticatedUrl(String unauthenticatedUrl) {
    16         this.unauthenticatedUrl = unauthenticatedUrl;
    17     }
    18 }
         RequestInterceptor.java定义非常简单,主要是在preHandler方法中验证了一下请求是否是登录用户发出的,否则响应给前端一个重定向。然后看一下PermissionUtils.isLogin(request)是怎样做登录验证的。
    PermissionUtils.java
     1 public class PermissionUtils {
     2 private static ThreadLocal<String> sessionToken = new ThreadLocal<String>();
     3  
     4 public static boolean isLogin(HttpServletRequest request){
     5     String token = sessionToken(request);
     6     if(StringUtils.isEmpty(token))
     7         return false;
     8     /**
     9     * 使用token检查是否存在登录session
    10     */
    11     //Session session = SecurityUtils.getSecurityManager().getSession(new WebSessionKey(token, request, response));
    12     Session session = SecurityUtils.getSecurityManager().getSession(new DefaultSessionKey(token));
    13     if(session != null){
    14         session.touch();
    15         sessionToken.set(token);
    16         return true;
    17     }
    18     return false;
    19 }
    20  
    21 private static String sessionToken(HttpServletRequest request){
    22     return request.getHeader("token");
    23 }
    24 }
         从PermissionUtils.java可以判断,保存前后端session的方式是通过token的形式。也即是每次request中的header部分都携带了登录成功后获取的token,以token为标识获取登录用户的session。特别地,对于Shiro而言,session并非特定于Web应用,Shiro有自己的session定义,可以独立于应用环境而存在。因此为了追求简单(既已弃用了Shiro针对web.xml应用提供的Filter),直接使用Shiro创建的默认session(实际是SimpleSession)。此外,需要说明的一个细节是通过Shiro的SecurityManager 返回的session实际都是一个代理(DelegatingSession的实例)。因此,通过 SecurityManager获取的session,然后对session执行的动作实际都是通过 SecurityManager的SessionManager来完成的(因为共享session,每一次session的touch动作都应该反映到共享session中,后文,可以看到overwrite SessionManager#touch(SessionKey key)和start session)。Shiro提供的默认SessionManager都继承了AbstractValidatingSessionManager$sessionValidationSchedulerEnabled属性,该属性控制了是否执行一个后台守护线程(Thread#setDaemon(true))在给定的一个固定时间间隔(默认1个小时)内周期性的检查session是否过期,并且在每一次获取到session之后都会去检查session是否过期(对于共享session的集群,共享缓存基本都已具备超时管理功能,所以可以重新实现后文提到的 AbstractNativeSessionManager#getSession(SessionKey))。PermissionUtils.java中定义了一个ThreadLocal类型的sessionToken变量,该变量是用于暂存当前request authentication成功之后的session标识,避免每次获取token都要从request中拿(后文中使用到的每一个url的authorization都需要首先执行一次checkPermission方法,通过token来验证是否有访问权限)。
        
         接下来描述Authentication和Authorization,具体地说明如何基于Shiro实现login和check permission。下面先给出applicationContext配置。
    applicationContext.xml
    <bean id="securityManager" class="org.apache.shiro.mgt.DefaultSecurityManager">
      <property name="realm" ref="authorizingRealm" />
      <property name="sessionManager">
          <bean class="service.authorizing.shiro.RedisSessionManager" >
            <property name="globalSessionTimeout" value="${session.timeout}" />
          </bean>
      </property>
    </bean>
    <bean id="realmCache" class="service.authorizing.shiro.cache.RedisShiroCache" />
    <bean id="authorizingRealm" class="service.authorizing.shiro.DefaultAuthorizingRealm">
      <property name="authorizationCachingEnabled" value="true"/>
      <property name="authorizationCache" ref="realmCache" />
    </bean>
    <bean id="lifecycleBeanPostProcessor" class="org.apache.shiro.spring.LifecycleBeanPostProcessor"/>
     
    <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
      <property name="staticMethod" value="org.apache.shiro.SecurityUtils.setSecurityManager"/>
      <property name="arguments" ref="securityManager"/>
    </bean>
         applicationContext.xml中配置的DefaultSecurityManager,RedisSessionManager,DefaultAuthorizingRealm和RedisShiroCache,分别代表Shiro的默认SecurityManager,自定义基于Redis的session manager,继承自Shiro的AuthorizingRealm的默认实现,以及自定义基于Redis的用户权限相关的Cache<Object, AuthorizationInfo>实现。注意到,本文的应用场景虽然是web.xml应用,但是并没有使用Shiro提供的 DefaultWebSecurityManager和DefaultWebSessionManager这两个针对web应用的拓展。使用针对web应用的拓展实现自然也没问题,但是个人认为对于纯粹的前后端分离权限认证的应用场景中,前端和后端应当是完全独立的,它们之间唯一的耦合是通过Http request交互的token。因此就目前简单和初期的原则,不需要DefaultWebSecurityManager和DefaultWebSessionManager。
    图2 Shiro组件交互过程
         在讲解程序具体怎样执行login和check permission之前,先看图2所示的Shiro各组件的交互过程,可以看到Real是安全验证的依据。所以有必要先理解Shiro提供的abstract类AuthorizingRealm,该类定义了两个抽象方法doGetAuthorizationInfo和doGetAuthenticationInfo,分别用于check permission和login验证。具体如下DefaultAuthorizingRealm.java的定义:
     
    DefaultAuthorizingRealm.java
     1 public class DefaultAuthorizingRealm extends AuthorizingRealm {
     2  
     3 @Autowired
     4 private AuthorizingService authorizingService;
     5  
     6     /**
     7     * 获取登录用户角色和功能权限信息,
     8     * 使用{@link org.apache.shiro.cache.CacheManager}和{@link org.apache.shiro.cache.Cache}获取数据.
     9     * @param principals 登录用户ID
    10     * @return
    11     */
    12     protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
    13         Object username =principals.getPrimaryPrincipal();
    14         Cache<Object, AuthorizationInfo> infoCache = getAuthorizationCache();
    15         AuthorizationInfo info = infoCache.get(username);
    16         return info;
    17     }
    18  
    19     /**
    20     * 根据登录用户token,获取用户信息。
    21     * 对于session timeout时间较短的场景可以考虑使用AuthenticationCache
    22     * 若验证失败,会抛出异常 {@link AuthenticationException}
    23     * @param token
    24     * @return
    25     * @throws AuthenticationException
    26     */
    27     protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
    28         Object username = token.getPrincipal();
    29         //对于session timeout时间较短的场景,可缓存用户authentication信息
    30         //Cache<Object, AuthenticationInfo> infoCache = getAuthenticationCache();
    31         //return infoCache.get(username);
    32         return authorizingService.authentication(username);
    33     }
    34 }
     
         DefaultAuthorizingRealm.java的实现,可以看到用户只需要通过 doGetAuthorizationInfo和doGetAuthenticationInfo两个方法给Shiro的SecurityManager提供Authorization和Authentication信息,SecurityManager就会在执行check permission和login操作时自动调用这两个函数来验证操作。下面我们再看执行login和check permission操作时具体做了什么。
     
    • Authentication
         下面在LoginController.java定义了login请求操作。
     
    LoginController.java
     1 @Controller
     2 @RequestMapping("/admin")
     3 public class LoginController {
     4   Logger logger = LoggerFactory.getLogger(LoginController.class);
     5  
     6   @Autowired
     7   private AuthorizingService authorizingService;
     8  
     9   @RequestMapping("/login")
    10   @ResponseBody
    11   public LoginToken login(User user, HttpServletRequest request){
    12       Subject subject = new Subject.Builder().buildSubject();
    13       UsernamePasswordToken token = new UsernamePasswordToken(userName, UtilTool.md5Tool(password));
    14       token.setRememberMe(true);
    15       LoginToken loginToken = new LoginToken();
    16       try{
    17            subject.login(token);
    18            Session session = subject.getSession();
    19            user.setToken((String) session.getId());
    20            loginToken.setResultCode(WebConstants.RESULT_SUCCESS_CODE);
    21       } catch (AuthenticationException e) {
    22            loginToken.setResultCode(WebConstants.RESULT_FAIL_CODE);
    23            loginToken.setMessage("用户名或密码错误!");
    24       }
    25       return loginToken;
    26   }
    27 }
         上述login代码只做了非常简单用户名和密码的验证示例。可以看出login如果没有抛出AuthenticationExeception,则说明登录成功。
     
    • Authorization
         访问权限控制需要在所有的访问controller的函数中配置,因此使用工具类最合适(在工具类的基础上做成spring annotation也可以很方便),既是PermissionUtils.java。
     
    PermissionUtils.java
     1 private static AuthorizingService authorizingService;
     2  
     3 private static ThreadLocal<String> sessionToken = new ThreadLocal<String>();
     4  
     5 /**
     6 *
     7 * @param url eg: /admin/review
     8 * @param argv eg: WAIT_BIZ_MANAGER
     9 */
    10 public static void checkPermission(String url, @Nullable String argv){
    11     Subject subject = getSubject();
    12     String permissionCode = authorizingService.uriMappingCode(url, argv);
    13     if(StringUtils.isEmpty(permissionCode))
    14         throw new IllegalArgumentException("不明操作");
    15     subject.checkPermission(permissionCode);
    16 }
    17  
    18 public static Subject getSubject(){
    19     String token = sessionToken.get();
    20     if(StringUtils.isEmpty(token))
    21         throw new AuthenticationException("未经认证");
    22     return new Subject.Builder()
    23             .sessionId(sessionToken.get())
    24             .buildSubject();
    25 }
    26  
    27 public static void setAuthorizingService(AuthorizingService authorizingService) {
    28     PermissionUtils.authorizingService = authorizingService;
    29 }
         从上述代码来看,每一个request的checkPermission操作,都需要依赖前文RequestInterceptor.java中提到的,从request中获取的token,并依赖该token找到缓存的session 。在权限控制的设计时,不同的业务场景可能需要不同粒度的权限控制,在这里做到了request参数级别的权限控制(在workflow应用中,一个流程涉及多个角色的参与,但很可能只抽象一个接口,如下文的/review操作)。在实现的时,灵活的方式是可以维护一张uri和permission_code之间的关系表(简单可以propertites文件)。对于前端用户而言,为了提升用户体验,拥有不同权限的用户得到的界面会有相应的隐藏和显示,因此会给前端的登录用户提供一张可访问权限表。在这里一个细节的设计,个人觉得有意义的是,在返回给前端的权限表的Key值不应当是permission_code,而是uri。因为permission_code对于前端而言毫无意义,而uri正是前后端沟通的桥梁。因此,check Permission操作可以如下:
     
    ReviewApiController.java
     
     1 @RestController
     2 @RequestMapping(value = "/review")
     3 public class ReviewApiController {
     4  
     5     @Autowired
     6     private ReviewService reviewService;
     7  
     8     @ResponseBody
     9     @RequestMapping(value = "/review", method = POST)
    10     public WebResult review(@RequestBody NewReviewVo reviewVo){
    11         //检查访问权限
    12         PermissionUtils.checkPermission("/review/review", reviewVo.getFeatureCode());
    13         WebResult result = WebResult.successResult();
    14         try {
    15             Review review = ReviewAssembler.voToReview(reviewVo);
    16             reviewService.review(review);
    17         }catch (Exception e){
    18             result = WebResult.failureResult(e.getMessage());
    19         }
    20         return result;
    21     }
    22
    • SessionManager
         由于要实现有选择的共享session数据,因此session管理成了最棘手的问题,因为你不是粗暴地将整个session序列化到缓存并仍以local session的方式管理,其间需要额外得小心处理共享的session数据和本地的session数据。下面给出RedisSessionManager.java的实现:
     
    RedisSessionManager.java
      1 /**
      2 * 根据 attributeKey,有选择的缓存session信息;
      3 * 设置 {@parm enabledSharedSessionData}来有选择的启用共享session功能。
      4 */
      5 public class RedisSessionManager extends DefaultSessionManager {
      6  
      7     private static Logger logger = LoggerFactory.getLogger(RedisSessionManager.class);
      8  
      9     private boolean enabledSharedSessionData;
     10  
     11     private Set<String> sharedSessionDataKeys;
     12  
     13     public RedisSessionManager() {
     14         enabledSharedSessionData = true;
     15         sharedSessionDataKeys = new HashSet<String>();
     16     }
     17  
     18     @Override
     19     public Collection<Object> getAttributeKeys(SessionKey key) {
     20  
     21         Collection<Object> keys = super.getAttributeKeys(key);
     22         if(enabledSharedSessionData) {
     23             /**
     24             * 从redis获取 {@param key} 对应session的所有attribute key
     25             */
     26             Set sharedKeys = RedisClient.extractAttributeKey((String) key.getSessionId());
     27             keys.addAll(sharedKeys);
     28         }
     29         return keys;
     30     }
     31  
     32     @Override
     33     public Object getAttribute(SessionKey sessionKey, Object attributeKey)
     34             throws InvalidSessionException {
     35         if(checkSharedStrategy(attributeKey)){
     36             Object object = RedisClient.getValue((String) attributeKey, (String) sessionKey.getSessionId());
     37             return object;
     38         }
     39         return super.getAttribute(sessionKey, attributeKey);
     40     }
     41  
     42     @Override
     43     public void setAttribute(SessionKey sessionKey, Object attributeKey, Object value)
     44             throws InvalidSessionException {
     45         if(checkSharedStrategy(attributeKey)) {
     46             if(value instanceof Serializable)
     47                 RedisClient.setValue((String) attributeKey, (String) sessionKey.getSessionId(),
     48                         (Serializable) value, getGlobalSessionTimeout(), TimeUnit.MILLISECONDS);
     49             else
     50                 throw new IllegalArgumentException("不可共享非序列化value");
     51             return;
     52         }
     53         super.setAttribute(sessionKey, attributeKey, value);
     54     }
     55  
     56     private boolean checkSharedStrategy(Object attributeKey){
     57         return enabledSharedSessionData && sharedSessionDataKeys.contains(attributeKey);
     58     }
     59  
     60     /**
     61     * 如果是集群, session只在一台机器上创建,因此必须共享 SessionId。
     62     * 当request发过来,获取request中携带的 SessionId,使用 SessionId 在本地获取session,
     63     * 如果为null,则用 SessionId 去redis检查是否存在,如果存在则在本地构建session返回
     64     * (实际就是{@link SimpleSession}的代理{@link DelegatingSession},{@see RedisSessionManager#restoreSession}),
     65     * 否则返回空, 请求重新登录。
     66     * {@link org.apache.shiro.session.mgt.AbstractNativeSessionManager#getSession(SessionKey)}
     67     * @param key
     68     * @return
     69     * @throws SessionException
     70     */
     71     @Override
     72     public Session getSession(SessionKey key) throws SessionException {
     73         Session session = null;
     74         try {
     75             session = getLocalSession(key);
     76         } catch (UnknownSessionException use){
     77             //ignored
     78             session = null;
     79         }
     80         if(!enabledSharedSessionData || session != null)
     81             return session;
     82         /**
     83         * 检查redis,判断session是否已创建,
     84         * 若已创建,则使用SessionFactory在本地构建SimpleSession
     85         */
     86         Serializable sid = RedisClient.getValue((String) key.getSessionId());
     87         if(sid != null){
     88             session = restoreSession(key);
     89         }
     90  
     91         return session;
     92     }
     93  
     94     /**
     95     * 每一次通过
     96     * {@link org.apache.shiro.session.mgt.AbstractValidatingSessionManager#doGetSession(SessionKey)}}
     97     * 获取session
     98     * 或是通过{@link org.apache.shiro.session.mgt.ExecutorServiceSessionValidationScheduler}
     99     * 定时检查,都会去调用
    100     * {@link org.apache.shiro.session.mgt.AbstractValidatingSessionManager#doValidate(Session)}
    101     * 验证session是否过期。
    102     * 共享session过期的标准是该redis中sessionId过期, 由于redis已经帮助完成了session过期检查,
    103     * 所以这里只需要定期清理本地内存中的过期session。
    104     * 然而{@link org.apache.shiro.session.mgt.AbstractValidatingSessionManager#doGetSession(SessionKey)}}
    105     * 是一个final方法,无法被overwrite,所以只能copy Shiro原来的代码实现来定义getLocalSession(SessionKey key)
    106     * @param key
    107     * @return
    108     */
    109     private Session getLocalSession(SessionKey key){
    110         Session session = lookupSession(key);
    111         return session != null ? createExposedSession(session, key) : null;
    112     }
    113     private Session lookupSession(SessionKey key) throws SessionException {
    114         if (key == null) {
    115             throw new NullPointerException("SessionKey argument cannot be null.");
    116         }
    117         //enableSessionValidationIfNecessary
    118         SessionValidationScheduler scheduler = getSessionValidationScheduler();
    119         if (enabledSharedSessionData ||
    120                 (isSessionValidationSchedulerEnabled() && (scheduler == null || !scheduler.isEnabled()))
    121                 ) {
    122             enableSessionValidation();
    123         }
    124         Session s = retrieveSession(key);
    125         if (!enabledSharedSessionData && s != null) {
    126             validate(s, key);
    127         }
    128         return s;
    129     }
    130  
    131     /**
    132     * 根据{@link SessionKey}以及继承自{@link DefaultSessionManager}的默认创建方法,
    133     * 重新在本地构建session。
    134     * @param key
    135     * @return
    136     */
    137     private Session restoreSession(SessionKey key){
    138         SimpleSession restoreSession = (SimpleSession) getSessionFactory().createSession(null);
    139         restoreSession.setId(key.getSessionId());
    140         restoreSession.setTimeout(getGlobalSessionTimeout());
    141         create(restoreSession);
    142         return createExposedSession(restoreSession, key);
    143     }
    144  
    145     /**
    146     * 开启一个新的session, 并且在新的session开启之后做一系列的session共享工作。
    147     * {@link org.apache.shiro.session.mgt.AbstractNativeSessionManager#start(SessionContext)}
    148     * @param context
    149     * @return
    150     */
    151     @Override
    152     public Session start(SessionContext context) {
    153         Session session = super.start(context);
    154         if(enabledSharedSessionData){
    155              shareSessionData(session);
    156         }
    157         return session;
    158     }
    159 /**
    160 * 完成session基本数据共享
    161 */
    162     private void shareSessionData(Session session){
    163         refreshTTL(session.getId());
    164     }
    165      /**
    166      * 刷新session存活时间
    167      */
    168     private void refreshTTL(Serializable sessionId){
    169         RedisClient.setValue((String) sessionId, new Date(),
    170                 getGlobalSessionTimeout(), TimeUnit.MILLISECONDS);
    171     }
    172  
    173     /**
    174     * {@link org.apache.shiro.session.mgt.AbstractNativeSessionManager#touch(SessionKey)}
    175     * @param key
    176     * @throws InvalidSessionException
    177     */
    178     @Override
    179     public void touch(SessionKey key) throws InvalidSessionException {
    180   if(enabledSharedSessionData){
    181        //刷新session存活时间
    182        refreshTTL(key.getSessionId());
    183         }
    184         super.touch(key);
    185     }
    186  
    187 /**
    188 * 当主动调用{@link Subject#logout()}时,相应会调用该方法来停止session。
    189 * 因此,如果共享了session,也需要即时清除共享session。
    190 * {@link org.apache.shiro.session.mgt.AbstractNativeSessionManager#stop(SessionKey)}
    191 * @param key
    192 * @throws InvalidSessionException
    193 */
    194 @Override
    195 public void stop(SessionKey key) throws InvalidSessionException {
    196     super.stop(key);
    197     if(enabledSharedSessionData)
    198         RedisClient.delete((String) key.getSessionId());
    199 }
    200  
    201     /**
    202     * {@link org.apache.shiro.session.mgt.AbstractNativeSessionManager#getLastAccessTime(SessionKey)}
    203     * @param key
    204     * @return
    205     */
    206     @Override
    207     public Date getLastAccessTime(SessionKey key) {
    208         Serializable lastAccessTime = enabledSharedSessionData ?
    209              RedisUtils.getValue((String) key.getSessionId()) :
    210              super.getLastAccessTime(key);
    211         if(lastAccessTime == null)
    212             throw new SessionTimeoutException();
    213         return (Date) lastAccessTime;
    214     }
    215  
    216     /**
    217     * 通知session manager那些attribute key对应的数据需要共享。
    218     * @param key
    219     */
    220     public void registerSharedAttributeKey(String key){
    221         if(!enabledSharedSessionData)
    222             throw new IllegalArgumentException("不允许共享session数据");
    223         if(sharedSessionDataKeys == null)
    224             sharedSessionDataKeys = new HashSet<String>();
    225         sharedSessionDataKeys.add(key);
    226     }
    227 }
    View Code
     
         由于Redis本身就是单线程模型,所以作为客户端基本不需要考虑线程安全问题。下面就各个问题来详细说明 RedisSessionManager。既然需求是想要实现在集群和分布式环境下,有选择的共享session数据,这意味着有一下问题需要处理:1,怎样做到有选择的共享session数据?2,本地session过期了怎样清理,以及怎样避免Shiro每次获取本地session都会进行过期验证和Redis的过期验证之间的重复? 3,怎样管理session存活时间?4,session只在一台机器上创建,既然不是共享了整个session,那么其它机器如何重建session?
         对于第1个问题,RedisSessionManager.java定义了enabledSharedSessionData和sharedSessionDataKeys两个变量来控制session数据共享,如果要求共享session数据,则需要通过registerSharedAttributeKey(String key)来告知session manager那些attribute key需要被共享,并定义checkSharedStrategy(Object attributeKey) 方法来检查attribute key是否共享。余下就是overwrite getter/setter attribute方法就可以了。这里再提一下,对于设置enabledSharedSessionData=true,除非是一定要通过共享缓存的方式共享session,否则还是使用Shiro默认的session管理,毕竟增加独立缓存就意味着维护成本的提高和可用性的下降。
         对于第2个问题,Shiro提供的session manager已经完成了local session的管理动作,因此我们只需要把local session的管理操作直接交给Shiro提供的默认session manager就可以了,而对于共享的session数据,Redis已经提供了数据过期管理功能(或者其它缓存工具基本都提供了)。因为Shiro提供的session manager清理session的原则是session已经过期或已经stop,那么session manager是怎样自动让session进入过期状态的呢?从AbstractNativeSessionManager#getSession(SessionKey)方法就可以追溯到,每一次通过该方法获取session不为空,都会调用SimpleSesion#validate()方法来验证session是否过期。此外,Shiro也提供了ExecutorServiceSessionValidationScheduler类来开启一个后台的固定周期执行的守护线程来执行session验证。既然Redis已经可以做到session有效性管理,那就没必要在每次获取session的时候都去主动的验证一次session。然而,getSession操作实际,Shiro提供的实现实际是调用了一个final类型AbstractValidatingSessionManager#doGetSession(SessionKey)方法,这意味着无法通过overwrite的方式来避免主动调用SimpleSesion#validate()。因此,在自定义sesssion manager中定义了getLocalSession(SessionKey key)方法,该方法本质实际是参照Shiro提供的实现,并在基础之上加上场景约束。
         对于第3个问题,在解释第2问题时已提到,Redis已自带超时管理功能,因此session存活时间只需要由Redis管理即可,而Shiro只需要开启一个固定周期的后台任务来清理本地无效session即可。
         对于第4个问题,在前后端完全分离的应用场景下,用户authentication通过之后由Shiro自动创建的session,里面包含的大部分数据都是可选共享的,而Shiro提供的最核心的Session实现,实际就是允许空参构造函数的SimpleSession。所以,实际我们只需共享出全局唯一的sessionId(shareSessionData(Session session) 方法实现),即可使用session manager提供的getSessionFactory()方法获取默认session factory,然后通过该factory即可创建SimpleSession并设置相应的共享数据,即restoreSession(SessionKey key)方法定义的过程。在Shiro提供的默认session manager中可以看到,所有的session创建都是通过AbstractNativeSessionManager#start(SessionContext)完成的,所以只需要overwrite这个方法并共享新创建session的必要数据即可。最后,结合问题2中提到的getLocalSession(SessionKey key)方法,获取session的方法getSession(SessionKey key)的实现分为两步:第一步是通过 getLocalSession(SessionKey key) 获取;如果第一步返回null且Redis中session未过期,则第二步通过restoreSession(SessionKey key)在本地重建session 。特别地,从refreshTTL(Serializable sessionId)方法的定义,可以看到共享sessionId的同时,对应的存放了该session的LastAccessTime。
     
    4,Authentication和Authorization执行时序
         在第3部分,已经给出了一个基本的基于Shiro的前后端分离的共享session实战范例,因此在这一部分将基于第3部分,通过时序图来表述Authentication和Authorization的执行流程。
    • 简要的合并时序
    图3 合并时序
    • Authentication时序

    图4 Authentication时序

    • Authorization时序

    图4 Authorization时序

    5,总结
         在使用Shiro框架进行Authentication和Authorization实践时,虽然根据不同的业务场景需要做不同的修改或调整,但是基本也是最佳的实践方式是时刻围绕Shiro的设计原则和已有可借鉴的实现方案来操作,尽可能少或者不修改,从而避免一些预想不到的Bug。最后,重提前言部分说到的,除非是一定要通过共享缓存的方式共享session,否则还是使用Shiro默认的session管理。
  • 相关阅读:
    Linux用户、用户组、文件权限设置
    spring,springMvc和mybatis整合配置
    spring,springMvc和hibernate整合
    spring与mybatis
    spring与Dbcp
    初识事物
    spring与Aop
    初识spring
    mysql 完整性约束
    mysql数据库的基本操作
  • 原文地址:https://www.cnblogs.com/shenjixiaodao/p/7426594.html
Copyright © 2011-2022 走看看