shiro源碼解析-doFilter
- 2019 年 10 月 30 日
- 筆記
shiro應該算的上java中最流行的許可權框架了，使用的多了，便想著研究一下源碼，看它究竟怎麼運行的。
doFilter是shiro對於每個請求都會走的一個效驗過程。它的流程如下
從DelegatingFilterProxy開始，執行dofilter()，這裡是一個代理模式，執行的是WebApplicationContext中的filter執行的dofilter方法，這個filter就是shiroFilter.從OncePerRequestFilter開始跟蹤，它的執行dofilter()。在dofilter()中，只有這個一個判斷，就是已經執行過shiro filter的請求不會再去執行shiro filter，實現方式是在http attribute中set一個屬性（filter類名.FILTERED），即shiroFilter.FILTERED。接著執行invokeDelegate調用代理對象的dofilter()方法
@Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException { // Lazily initialize the delegate if necessary. Filter delegateToUse = this.delegate; if (delegateToUse == null) { synchronized (this.delegateMonitor) { delegateToUse = this.delegate; if (delegateToUse == null) { WebApplicationContext wac = findWebApplicationContext(); if (wac == null) { throw new IllegalStateException("No WebApplicationContext found: " + "no ContextLoaderListener or DispatcherServlet registered?"); } delegateToUse = initDelegate(wac); } this.delegate = delegateToUse; } } // 調用代理對象的dofilter方法 invokeDelegate(delegateToUse, request, response, filterChain); }
protected void invokeDelegate( Filter delegate, ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException { delegate.doFilter(request, response, filterChain); }
delegatefilter的跟蹤從AbstractShiroFilter這個父類開始，它是OncePerRequestFilter的子類，OncePerRequestFilter會調用doFilterInternal抽象方法，AbstractShiroFilter去實現它。在doFilterInternal方法中，它會包裝request，response，接著將包裝後的request，response處理，使用的ServletRequestWrapper，ServletResponseWrapper，但是包裝對象還是原始的request和response，沒有替代。這麼做的原因應該是便於自定義擴展，比如做一些針對流的操作，流不可重複讀寫，而採用其他對象包裝後，可以把讀寫後的內容到另一個流里，再去返回。接著生成一個請求對應Subject，讓這個Subject去執行新執行緒的executeChain執行鏈。
為什麼不用執行緒池去管理執行緒，而要採用新建執行緒這種粗暴的方式執行filterChain鏈，難道Subject的數量是限制了？ 在源碼中，執行緒並沒有做大小的限制，subject也沒有做數量大小的限制，來一個請求就新增一個subject。這裡我們採用的方式是重寫SubjectFactory，通過redis去快取principals，根據快取principals，判斷快取authenticated，通過上面的參數，new Subject。繼承Subject，加上user屬性，快取user。
在executeChain()方法中，它會在根據請求url，在與FilterChainManager中所有的shiroFilter的chainName（定義的url名）比較，如果存在匹配，這返回對應的filterList。默認使用LinkedHashMap去存url與filterList。並將匹配filter包裝到一個FilterChain對象中。接著執行FilterChain。
final ServletRequest request = prepareServletRequest(servletRequest, servletResponse, chain); final ServletResponse response = prepareServletResponse(request, servletResponse, chain); final Subject subject = createSubject(request, response); //noinspection unchecked subject.execute(new Callable() { public Object call() throws Exception { updateSessionLastAccessTime(request, response); executeChain(request, response, chain); return null; } });
ProxiedFilterChain是FilterChain的shiro實現類，用於filters鏈的實現，實現方式很巧妙，在chain執行一個filter，並自增下標，在filter.doFilter()中又調用chain.doFilter，實現鏈的接下來filter的調用。這個做法是不怎麼標準的「責任鏈模式」。
public class ProxiedFilterChain implements FilterChain { private static final Logger log = LoggerFactory.getLogger(ProxiedFilterChain.class); private FilterChain orig; //web.xml配置的filter private List<Filter> filters; //shiro的filter private int index = 0; //執行到了哪一個filter public ProxiedFilterChain(FilterChain orig, List<Filter> filters) { // init property } public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException { if (this.filters == null || this.filters.size() == this.index) { this.orig.doFilter(request, response); } else { this.filters.get(this.index++).doFilter(request, response, this); } } }
這次執行的就是匹配filter執行dofilter，我們這裡匹配的filter是AuthenticatingFilter下的子類。它會先走AdviceFilter的doFilterInternal()。在doFilterInternal()，依次調用preHandle，executeChain，postHandle三個方法，就好像AOP的切面中的執行前，執行，執行後三個方法。preHandle就是這個filter驗證的邏輯，executeChain將調用chain.dofilter()，繼續執行下一個filter，postHandle()是遞歸回來後，去執行什麼操作，默認不執行任何操作。這樣執行鏈chain中所有filter，設計精巧，腦洞清奇。如果某個filter失效了，直接在preHandle()中用webTool.write寫返回，或默認跳轉頁面。
public void doFilterInternal(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException { Exception exception = null; try { boolean continueChain = preHandle(request, response); if (log.isTraceEnabled()) { log.trace("Invoked preHandle method. Continuing chain?: [" + continueChain + "]"); } if (continueChain) { executeChain(request, response, chain); } postHandle(request, response); if (log.isTraceEnabled()) { log.trace("Successfully invoked postHandle method"); } } catch (Exception e) { exception = e; } finally { cleanup(request, response, exception); } }
調用preHandle會先進入AccessControlFilter重寫的preHandle方法，它會判斷允許通過處理或禁止通過處理。用||判斷，所以isAccessAllowed通過了就不會再走onAccessDenied()。
這裡有一個設計的bug，就是訪問login介面的時候帶正確
token，它在isAccessAllowed方法中返回true，不會進入onAccessDenied。而生成並返回新token的處理一般就是在onAccessDenied中，它複雜未通過效驗的處理。 解決方法是，重寫isAccessAllowed方法，在方法中加上isLoginUrl()的判斷，如果是loginUrl，返回false，讓它走isAccessAllowed。
public boolean onPreHandle(ServletRequest request, ServletResponse response, Object mappedValue) throws Exception { return isAccessAllowed(request, response, mappedValue) || onAccessDenied(request, response, mappedValue); }
isAccessAllowed方法
@Override protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) { return super.isAccessAllowed(request, response, mappedValue) || (!isLoginRequest(request, response) && isPermissive(mappedValue)); }
AuthorizationFilter的onAccessDenied方法
protected boolean onAccessDenied(ServletRequest request, ServletResponse response) throws IOException { Subject subject = getSubject(request, response); // If the subject isn't identified, redirect to login URL if (subject.getPrincipal() == null) { saveRequestAndRedirectToLogin(request, response); } else { // If subject is known but not authorized, redirect to the unauthorized URL if there is one // If no unauthorized URL is specified, just return an unauthorized HTTP status code String unauthorizedUrl = getUnauthorizedUrl(); //SHIRO-142 - ensure that redirect _or_ error code occurs - both cannot happen due to response commit: if (StringUtils.hasText(unauthorizedUrl)) { WebUtils.issueRedirect(request, response, unauthorizedUrl); } else { WebUtils.toHttp(response).sendError(HttpServletResponse.SC_UNAUTHORIZED); } } return false; }
這是子AuthorizationFilter的onAccessDenied
Subject subject = getSubject(request, response); // If the subject isn't identified, redirect to login URL if (subject.getPrincipal() == null) { saveRequestAndRedirectToLogin(request, response); } else { // If subject is known but not authorized, redirect to the unauthorized URL if there is one // If no unauthorized URL is specified, just return an unauthorized HTTP status code String unauthorizedUrl = getUnauthorizedUrl(); //SHIRO-142 - ensure that redirect _or_ error code occurs - both cannot happen due to response commit: if (StringUtils.hasText(unauthorizedUrl)) { WebUtils.issueRedirect(request, response, unauthorizedUrl); } else { WebUtils.toHttp(response).sendError(HttpServletResponse.SC_UNAUTHORIZED); } }
實際上在我們項目中，只有一個filter執行，在preHandle()方法中驗證是否通過效驗，如果沒有通過，使用調用login介面，接著直接webTool.write，返回response，結束請求。
如果return ture，它接著執行filter，並由tomcat的filter WsFilter，進入程式介面。
dofilter流程圖
注意 spring的filter源碼也是這麼處理的，從
OncePerRequestFilter開始，做法一致。
總體來說，shiro的dofilter流程如下。首先進入shiro的主filter，這個filter的作用是獲得該url與shiro適配的filters，並把這個適配的List<filter>放入filterChain中去繼續執行。接著執行filteChain中的下一個filter，這個filter是FilterChain中的，它是shiro中篩選url的filter。這些filter都繼承AdviceFilter，去執行doFilterInternal()，doFilterInternal()依次執行preHandle，executeChain，postHandle三個方法，分別是判斷是否執行（具體filter的業務就是重寫preHandle，），執行鏈中的下一個filter，filter執行結束後的操作。AdviceFilter有的executeChain會調用下一個filter，從而實現所有filter的效驗。AccessControlFilter
