其實關於Shiro的一些學習筆記很早就該寫了，因為懶癌和拖延症晚期一直沒有落實，直到今天公司的一個專案碰到了在叢集環境的單點登入頻繁掉線的問題，為了解決這個問題，Shiro相關的文件和教程沒少翻。最後問題解決了，但我覺得我也是時候來做一波Shiro學習筆記了。

本篇是Shiro系列第四篇，Shiro中的過濾器初始化流程和實現原理。Shiro基於URL的許可權控制是通過Filter實現的，本篇從我們注入的ShiroFilterFactoryBean開始入手，翻看原始碼追尋Shiro中的過濾器的實現原理。

首發地址：https://www.guitu18.com/post/2019/08/08/45.html

Session

SessionManager

我們在配置Shiro時配置了一個DefaultWebSecurityManager，先來看下

DefaultWebSecurityManager

    public DefaultWebSecurityManager() {
        super();
        ((DefaultSubjectDAO) this.subjectDAO).setSessionStorageEvaluator(new DefaultWebSessionStorageEvaluator());
        this.sessionMode = HTTP_SESSION_MODE;
        setSubjectFactory(new DefaultWebSubjectFactory());
        setRememberMeManager(new CookieRememberMeManager());
        setSessionManager(new ServletContainerSessionManager());
    }
 

在它的構造方法中注入了一個ServletContainerSessionManager

public class ServletContainerSessionManager implements WebSessionManager {
    public Session getSession(SessionKey key) throws SessionException {
        if (!WebUtils.isHttp(key)) {
            String msg = "SessionKey must be an HTTP compatible implementation.";
            throw new IllegalArgumentException(msg);
        }
        HttpServletRequest request = WebUtils.getHttpRequest(key);
        Session session = null;
        HttpSession httpSession = request.getSession(false);
        if (httpSession != null) {
            session = createSession(httpSession, request.getRemoteHost());
        }
        return session;
    }
    
    private String getHost(SessionContext context) {
        String host = context.getHost();
        if (host == null) {
            ServletRequest request = WebUtils.getRequest(context);
            if (request != null) {
                host = request.getRemoteHost();
            }
        }
        return host;
    }

    protected Session createSession(SessionContext sessionContext) throws AuthorizationException {
        if (!WebUtils.isHttp(sessionContext)) {
            String msg = "SessionContext must be an HTTP compatible implementation.";
            throw new IllegalArgumentException(msg);
        }
        HttpServletRequest request = WebUtils.getHttpRequest(sessionContext);
        HttpSession httpSession = request.getSession();
        String host = getHost(sessionContext);
        return createSession(httpSession, host);
    }
    
    protected Session createSession(HttpSession httpSession, String host) {
        return new HttpServletSession(httpSession, host);
    }
}
 

ServletContainerSessionManager本身並不管理會話，它最終操作的還是HttpSession，所以只能在Servlet容器中起作用，它不能支援除使用HTTP協議的之外的任何會話。

所以一般我們配置Shiro都會配置一個DefaultWebSessionManager，它繼承了DefaultSessionManager，看看DefaultSessionManager的構造方法：

public DefaultSessionManager() {
    this.deleteInvalidSessions = true;
    this.sessionFactory = new SimpleSessionFactory();
    this.sessionDAO = new MemorySessionDAO();
}

這裡的sessionDAO初始化了一個MemorySessionDAO，它其實就是一個Map，在記憶體中通過鍵值對管理Session。

public MemorySessionDAO() {
    this.sessions = new ConcurrentHashMap<Serializable, Session>();
}

HttpServletSession

public class HttpServletSession implements Session {
    public HttpServletSession(HttpSession httpSession, String host) {
        if (httpSession == null) {
            String msg = "HttpSession constructor argument cannot be null.";
            throw new IllegalArgumentException(msg);
        }
        if (httpSession instanceof ShiroHttpSession) {
            String msg = "HttpSession constructor argument cannot be an instance of ShiroHttpSession.  This " +
                    "is enforced to prevent circular dependencies and infinite loops.";
            throw new IllegalArgumentException(msg);
        }
        this.httpSession = httpSession;
        if (StringUtils.hasText(host)) {
            setHost(host);
        }
    }
    protected void setHost(String host) {
        setAttribute(HOST_SESSION_KEY, host);
    }
    public void setAttribute(Object key, Object value) throws InvalidSessionException {
        try {
            httpSession.setAttribute(assertString(key), value);
        } catch (Exception e) {
            throw new InvalidSessionException(e);
        }
    }
}

Shiro的HttpServletSession只是對javax.servlet.http.HttpSession進行了簡單的封裝，所以在Web應用中對Session的相關操作最終都是對javax.servlet.http.HttpSession進行的，比如上面程式碼中的setHost()是將內容以鍵值對的形式儲存在httpSession中。

先來看下這張圖：

先了解上面這幾個類的關係和作用，然後我們想管理Shiro中的一些資料就非常方便了。

SessionDao是Session管理的頂層介面，定義了Session的增刪改查相關方法。

public interface SessionDAO {
    Serializable create(Session session);
    Session readSession(Serializable sessionId) throws UnknownSessionException;
    void update(Session session) throws UnknownSessionException;
    void delete(Session session);
    Collection<Session> getActiveSessions();
}

AbstractSessionDao是一個抽象類，在它的構造方法中定義了JavaUuidSessionIdGenerator作為SessionIdGenerator用於生成SessionId。它雖然實現了create()和readSession()兩個方法，但具體的流程呼叫的是它的兩個抽象方法doCreate()和doReadSession()，需要它的子類去幹活。

public abstract class AbstractSessionDAO implements SessionDAO {
    private SessionIdGenerator sessionIdGenerator;
    public AbstractSessionDAO() {
        this.sessionIdGenerator = new JavaUuidSessionIdGenerator();
    }
    
    public Serializable create(Session session) {
        Serializable sessionId = doCreate(session);
        verifySessionId(sessionId);
        return sessionId;
    }
    protected abstract Serializable doCreate(Session session);

    public Session readSession(Serializable sessionId) throws UnknownSessionException {
        Session s = doReadSession(sessionId);
        if (s == null) {
            throw new UnknownSessionException("There is no session with id [" + sessionId + "]");
        }
        return s;
    }
    protected abstract Session doReadSession(Serializable sessionId);
}

看上面那張類圖AbstractSessionDao的子類有三個，檢視原始碼發現CachingSessionDAO是一個抽象類，它並沒有實現這兩個方法。在它的子類EnterpriseCacheSessionDAO中實現了doCreate()和doReadSession()，但doReadSession()是一個空實現直接返回null。

    public EnterpriseCacheSessionDAO() {
        setCacheManager(new AbstractCacheManager() {
            @Override
            protected Cache<Serializable, Session> createCache(String name) throws CacheException {
                return new MapCache<Serializable, Session>(name, new ConcurrentHashMap<Serializable, Session>());
            }
        });
    }

EnterpriseCacheSessionDAO依賴於它的父級CachingSessionDAO，在他的構造方法中向父類注入了一個AbstractCacheManager的匿名實現，它是一個基於記憶體的SessionDao，它所建立的MapCache就是一個Map。

我們在Shiro配置類裡通過 sessionManager.setSessionDAO(new EnterpriseCacheSessionDAO()); 來使用它。然後在CachingSessionDAO.getCachedSession() 打個斷點測試一下，可以看到cache就是一個ConcurrentHashMap，在記憶體中以Key-Value的形式儲存著JSESSIONID和Session的對映關係。

再來看AbstractSessionDao的第三個實現MemorySessionDAO，它就是一個基於記憶體的SessionDao，簡單直接，構造方法直接new了一個ConcurrentHashMap。

    public MemorySessionDAO() {
        this.sessions = new ConcurrentHashMap<Serializable, Session>();
    }

那麼它和EnterpriseCacheSessionDAO有啥區別，其實EnterpriseCacheSessionDAO只是CachingSessionDAO的一個預設實現，在CachingSessionDAO中cacheManager是沒有預設值的，在EnterpriseCacheSessionDAO的構造方法將其初始化為一個ConcurrentHashMap。

如果我們直接用EnterpriseCacheSessionDAO其實和MemorySessionDAO其實沒有什麼區別，都是基於Map的記憶體型SessionDao。但是CachingSessionDAO的目的是為了方便擴充套件的，使用者可以繼承CachingSessionDAO並注入自己的Cache實現，比如以Redis快取Session的RedisCache。

其實在業務上如果需要Redis來管理Session，那麼直接繼承AbstractSessionDao更好，有Redis支撐中間的Cache就是多餘的，這樣還可以做分散式或叢集環境的Session共享（分散式或叢集環境如果中間還有一層Cache那麼還要考慮同步問題）。

回到開篇提到的我們公司專案叢集環境下單點登入頻繁掉線的問題，其實就是中間那層Cache造成的。我們的業務程式碼中RedisSessionDao是繼承自EnterpriseCacheSessionDAO的，這樣一來那在Redis之上還有一個基於記憶體的Cache層。此時使用者的Session如果發生變更，雖然Redis中的Session是同步的，Cache層沒有同步，導致的現象就是使用者在一臺伺服器的Session是有效的，另一臺伺服器Cache中的Session還是舊的，然後使用者就被迫下線了