1、默认存在哪些filter,具体执行顺序
-
ChannelProcessingFilter,如果你访问的 channel 错了,那首先就会在channel 之间进行跳转,如 http 变为 https。
-
SecurityContextPersistenceFilter,这样的话在一开始进行 request 的时候就可以在 SecurityContextHolder 中建立一个SecurityContext,然后在请求结束的时候,任何对 SecurityContext 的改变都可以被 copy 到 HttpSession。
-
ConcurrentSessionFilter,因为它需要使用 SecurityContextHolder 的功能,而且更新对应 session 的最后更
-
新时间,以及通过 SessionRegistry 获取当前的 SessionInformation 以检查当前的 session 是否已经过期,过期则会调用 LogoutHandler。
-
HeaderWriterFilter
-
CsrfFilter
-
LogoutFilter
-
X509AuthenticationFilter
-
AbstractPreAuthenticatedProcessingFilter
-
认证处理机制,如 UsernamePasswordAuthenticationFilter,CasAuthenticationFilter,BasicAuthenticationFilter 等,以至于 SecurityContextHolder 可以被更新为包含一个有效的 Authentication 请求。
-
SecurityContextHolderAwareRequestFilter,它将会把 HttpServletRequest 封装成一个继承自 HttpServletRequestWrapper 的 SecurityContextHolderAwareRequestWrapper,同时使用 SecurityContext 实现了 HttpServletRequest 中与安全相关的方法。
-
JaasApiIntegrationFilter,如果 SecurityContextHolder 中拥有的 Authentication 是一个 JaasAuthenticationToken,那么该 Filter 将使用包含在 JaasAuthenticationToken 中的 Subject 继续执行 FilterChain。
-
RememberMeAuthenticationFilter,如果之前的认证处理机制没有更新 SecurityContextHolder,并且用户请求包含了一个 Remember-Me 对应的 cookie,那么一个对应的 Authentication 将会设给 SecurityContextHolder。
-
AnonymousAuthenticationFilter,如果之前的认证机制都没有更新 SecurityContextHolder 拥有的 Authentication,那么一个 AnonymousAuthenticationToken 将会设给 SecurityContextHolder。
-
SessionManagementFilter
-
ExceptionTransactionFilter,用于处理在 FilterChain 范围内抛出的 AccessDeniedException 和 AuthenticationException,并把它们转换为对应的 Http 错误码返回或者对应的页面。
-
FilterSecurityInterceptor,保护 Web URI,并且在访问被拒绝时抛出异常。
2、重点了解SecurityContextPersistenceFilter,session是如何进行操作,做到任何对SecurityContext的改变都可以被copy到HttpSession中。
先查看其中doFilter方法的代码
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException {
.......
//省略部分代码
HttpRequestResponseHolder holder = new HttpRequestResponseHolder(request, response);
//获取SecurityContext,其中是从httpsession中获取,如果httpsession中没有,则新建并返回一个新的
SecurityContext contextBeforeChainExecution = repo.loadContext(holder);
try {
//将返回的securityContext保存到本地线程中,方便将来访问
SecurityContextHolder.setContext(contextBeforeChainExecution);
chain.doFilter(holder.getRequest(), holder.getResponse());
} finally {
//获取之前保存的securityContext
SecurityContext contextAfterChainExecution = SecurityContextHolder.getContext();
// Crucial removal of SecurityContextHolder contents - do this before anything else.
//清空SecurityContextHolder中的Context
SecurityContextHolder.clearContext();
//将Security保存到HttpSession中,下次请求的时候就可以利用保存好的SecurityContext
repo.saveContext(contextAfterChainExecution, holder.getRequest(), holder.getResponse());
request.removeAttribute(FILTER_APPLIED);
if (debug) {
logger.debug("SecurityContextHolder now cleared, as request processing completed");
}
}
}
再看一下loadContext方法
public SecurityContext loadContext(HttpRequestResponseHolder requestResponseHolder) {
HttpServletRequest request = requestResponseHolder.getRequest();
HttpServletResponse response = requestResponseHolder.getResponse();
HttpSession httpSession = request.getSession(false);
//从这就可以看出来,SecurityContext的获取就是从Httpsession中获得的,所以根据java的传址特性,就可以判断出Httpsession会同步SecurityContext的变化
SecurityContext context = readSecurityContextFromSession(httpSession);
if (context == null) {
if (logger.isDebugEnabled()) {
logger.debug("No SecurityContext was available from the HttpSession: " + httpSession +". " +
"A new one will be created.");
}
//如果当然session中没有SecurityContext,则重新创建一个新的Context
context = generateNewContext();
}
requestResponseHolder.setResponse(
new SaveToSessionResponseWrapper(response, request, httpSession != null, context));
return context;
}