Shiro踩坑记（二）：使用RequiresXXX的注解后，访问对应请求返回404
问题描述：
我在项目中的某个Controller上添加了@RequirePermissions注解，希望在执行该请求前，可以先进行权限验证。但是当我请求该Controller时，返回的确是404错误。
首先我怀疑的是因为权限不足而抛出了404错误。但是我发现我在AController的请求方法1上加了@RequiresPermession注释，但是请求方法2同样也报了404错误。所以应该不是shiro对权限进行了拦截，更像是整个controller的请求映射都没被Spring正常解析。
哪个步骤产生了404错误
我们知道SpringMVC处理请求转发的地方是在DispatchServlet的doDispatch方法中。
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
HttpServletRequest processedRequest = request;
HandlerExecutionChain mappedHandler = null;
boolean multipartRequestParsed = false;
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
try {
ModelAndView mv = null;
Exception dispatchException = null;
try {
//如果是Multipart请求，则先处理
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
// Determine handler for the current request.
//根据请求找到对应HandlerMapping，在通过HandlerMapping返回对应的处理器执行链HandlerExecuteChain
mappedHandler = getHandler(processedRequest);
//找不到对应的映射，则抛出404异常
if (mappedHandler == null) {
noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = "GET".equals(method);
//GET 和 HEAD请求 如果资源没更新，则直接返回
if (isGet || "HEAD".equals(method)) {
long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
if (logger.isDebugEnabled()) {
logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified);
}
if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
return;
}
}
//请求的预处理，其实就是应用拦截器的preHandle方法
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
//正式由Controller处理请求，
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
if (asyncManager.isConcurrentHandlingStarted()) {
return;
}
//根据Controller返回的视图名，解析视图
applyDefaultViewName(processedRequest, mv);
//后置处理，应用拦截器的后置处理方法
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
catch (Exception ex) {
dispatchException = ex;
}
catch (Throwable err) {
// As of 4.3, we're processing Errors thrown from handler methods as well,
// making them available for @ExceptionHandler methods and other scenarios.
dispatchException = new NestedServletException("Handler dispatch failed", err);
}
//处理异常或是渲染视图
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
catch (Exception ex) {
triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
}
catch (Throwable err) {
triggerAfterCompletion(processedRequest, response, mappedHandler,
new NestedServletException("Handler processing failed", err));
}
finally {
if (asyncManager.isConcurrentHandlingStarted()) {
// Instead of postHandle and afterCompletion
if (mappedHandler != null) {
mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
}
}
else {
// Clean up any resources used by a multipart request.
if (multipartRequestParsed) {
cleanupMultipart(processedRequest);
}
}
}
}
一种怀疑是在getHandler时，找不到对应的executeHandlerChain，所以产生了404错误。但是在断点中我们发现依旧可以获取到相应的executeHandlerChain。
貌似没有问题（其实如果够细心且了解MappingHandler的话，此时应该已经能看出问题了）。
继续往下，直到过了前置处理依旧没有问题（说明基本上不是拦截器造成的404错误）。
而再往下发现经过ha.handle()方法后，返回的mv对象为null，而此时看response对象已经出现了404的错误。
因此我们将关注点放在handle的执行顺序上。
我们得到的ha是HttpRequestHandlerAdapter对象。它的handle方法如下：
@Override
@Nullable
public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
throws Exception {
((HttpRequestHandler) handler).handleRequest(request, response);
return null;
}
HandlerAdapter是一个处理器适配器。主要是适配不同类型的处理器。而此时的Handler类型是ResourceHttpRequestHandler。
其中handleRequest方法如下：
@Override
public void handleRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// For very general mappings (e.g. "/") we need to check 404 first
//根据请求路径，解析对应的静态资源
Resource resource = getResource(request);
//如果找不到对应资源，则抛出404错误
if (resource == null) {
logger.trace("No matching resource found - returning 404");
response.sendError(HttpServletResponse.SC_NOT_FOUND);
return;
}
if (HttpMethod.OPTIONS.matches(request.getMethod())) {
response.setHeader("Allow", getAllowHeader());
return;
}
// Supported methods and required session
checkRequest(request);
// Header phase
if (new ServletWebRequest(request, response).checkNotModified(resource.lastModified())) {
logger.trace("Resource not modified - returning 304");
return;
}
// Apply cache settings, if any
prepareResponse(response);
// Check the media type for the resource
MediaType mediaType = getMediaType(request, resource);
if (mediaType != null) {
if (logger.isTraceEnabled()) {
logger.trace("Determined media type '" + mediaType + "' for " + resource);
}
}
else {
if (logger.isTraceEnabled()) {
logger.trace("No media type found for " + resource + " - not sending a content-type header");
}
}
// Content phase
if (METHOD_HEAD.equals(request.getMethod())) {
setHeaders(response, resource, mediaType);
logger.trace("HEAD request - skipping content");
return;
}
ServletServerHttpResponse outputMessage = new ServletServerHttpResponse(response);
if (request.getHeader(HttpHeaders.RANGE) == null) {
Assert.state(this.resourceHttpMessageConverter != null, "Not initialized");
setHeaders(response, resource, mediaType);
this.resourceHttpMessageConverter.write(resource, mediaType, outputMessage);
}
else {
Assert.state(this.resourceRegionHttpMessageConverter != null, "Not initialized");
response.setHeader(HttpHeaders.ACCEPT_RANGES, "bytes");
ServletServerHttpRequest inputMessage = new ServletServerHttpRequest(request);
try {
List<HttpRange> httpRanges = inputMessage.getHeaders().getRange();
response.setStatus(HttpServletResponse.SC_PARTIAL_CONTENT);
this.resourceRegionHttpMessageConverter.write(
HttpRange.toResourceRegions(httpRanges, resource), mediaType, outputMessage);
}
catch (IllegalArgumentException ex) {
response.setHeader("Content-Range", "bytes */" + resource.contentLength());
response.sendError(HttpServletResponse.SC_REQUESTED_RANGE_NOT_SATISFIABLE);
}
}
}
其中需要关系的部分是getResource方法，因为找不到对应的Resource，而产生了404错误。我们也找到了404错误的原因。
找到404的原因后，继续分析。ResourceHttpRequestHandler是负责处理静态资源的。正常情况下，我们到控制器的请求不应该是由ResourceHttpRequestHandler处理。因此，我们得到的Handler并非是我们期望的。
getHandler解析的Handler为什么不对
首先看DispatchServlet的getHandler方法。
@Nullable
protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
if (this.handlerMappings != null) {
//遍历内部的HandlerMapping（内置处理器），返回该请求映射的处理器
for (HandlerMapping hm : this.handlerMappings) {
if (logger.isTraceEnabled()) {
logger.trace(
"Testing handler map [" + hm + "] in DispatcherServlet with name '" + getServletName() + "'");
}
//返回处理器，并形成处理器链
HandlerExecutionChain handler = hm.getHandler(request);
if (handler != null) {
return handler;
}
}
}
return null;
}
DispatcherServlet在初始化时会创建内置的一些HandlerMapping。常见的有SimpleUrlHandlerMapping（映射请求和静态资源），RequestMappingHandlerMapping（映射请求和@RequestMapping注解的Controller中的方法），BeanNameUrlHandlerMapping（映射请求和处理器bean，映射关系由bean Name确定）等。
为什么RequestMappingHandlerMapping没能够为我们对应的处理器？了解下RequestMappingHandlerMapping的getHandler方法：
public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
//调用内部获取处理器的方法(模板模式)
Object handler = getHandlerInternal(request);
//如果处理器为空 则使用默认的处理器
if (handler == null) {
handler = getDefaultHandler();
}
if (handler == null) {
return null;
}
//如果返回的处理器是bean Name，则获取bean对象
// Bean name or resolved handler?
if (handler instanceof String) {
String handlerName = (String) handler;
handler = obtainApplicationContext().getBean(handlerName);
}
//形成处理器执行链（主要是添加拦截器）
HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);
//如果是跨域请求，则设置跨域的配置
if (CorsUtils.isCorsRequest(request)) {
CorsConfiguration globalConfig = this.globalCorsConfigSource.getCorsConfiguration(request);
CorsConfiguration handlerConfig = getCorsConfiguration(handler, request);
CorsConfiguration config = (globalConfig != null ? globalConfig.combine(handlerConfig) : handlerConfig);
executionChain = getCorsHandlerExecutionChain(request, executionChain, config);
}
return executionChain;
}
查找处理器的逻辑主要是是在getHandlerInternal方法中：
protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
//根据请求解析路径
String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
if (logger.isDebugEnabled()) {
logger.debug("Looking up handler method for path " + lookupPath);
}
this.mappingRegistry.acquireReadLock();
try {
//获取对应的处理器方法
HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);
if (logger.isDebugEnabled()) {
if (handlerMethod != null) {
logger.debug("Returning handler method [" + handlerMethod + "]");
}
else {
logger.debug("Did not find handler method for [" + lookupPath + "]");
}
}
return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null);
}
finally {
this.mappingRegistry.releaseReadLock();
}
}
而lookupHandlerMethod方法则是从MappingRegistry中获取匹配url的方法。在根据URL匹配的精度确认最后的方法。ReqeustMappingHandlerMapping找不到处理器，说明MappingRegistry并没有解析到对应的处理器方法。
RequstMappingHandlerMapping的初始化过程
RequestMappingHandlerMapping实现了InitializingBean接口。在其afterPropertiesSet方法中实现了将
处理器映射方法mappingRegistry的逻辑。具体实现在其父类AbstractHandlerMethodMapping中。
//初始化时检测处理器方法
@Override
public void afterPropertiesSet() {
initHandlerMethods();
}
//扫描上下文中的bean，注册对应的处理器方法
protected void initHandlerMethods() {
if (logger.isDebugEnabled()) {
logger.debug("Looking for request mappings in application context: " + getApplicationContext());
}
//获取上下文中的bean name
String[] beanNames = (this.detectHandlerMethodsInAncestorContexts ?
BeanFactoryUtils.beanNamesForTypeIncludingAncestors(obtainApplicationContext(), Object.class) :
obtainApplicationContext().getBeanNamesForType(Object.class));
//遍历bean names
for (String beanName : beanNames) {
if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX)) {
Class<?> beanType = null;
try {
beanType = obtainApplicationContext().getType(beanName);
}
catch (Throwable ex) {
// An unresolvable bean type, probably from a lazy bean - let's ignore it.
if (logger.isDebugEnabled()) {
logger.debug("Could not resolve target class for bean with name '" + beanName + "'", ex);
}
}
//是否为标准处理器（RequestMappingHandlerMapping的实现根据类上是否有@Controller或是@RequestMapping注释）
if (beanType != null && isHandler(beanType)) {
//筛选对应的方法并注册
detectHandlerMethods(beanName);
}
}
}
handlerMethodsInitialized(getHandlerMethods());
}
接下来就是在RequestMappingHandlerMapping初始化的过程中断点调试，看看是什么问题：
可以看到相应的控制器被代理过后丢失了注释。而这里的代理并非是AspectJ的创建的，而是com.sun.Proxy对象。
如果在启动时观察对应控制器的bean的创建情况，可以发现这个bean被增强了两次：
第一次增强：
第二次增强：
可以看到第二次增强过后bean丢失了@Controller的注释。
解决方案
我们已经知道造成404的真正原因是Controller初始化时被增强了两次。并在第二次增强时丢掉了注释。导致了该Controller无法被正常映射。因此我们只需要关闭一次增强过程即可。事实上，由于已经存在了ProxyCreator，因此ShiroAnnotationProcessorAutoConfiguration中的DefaultAdvisorAutoProxyCreator就不再需要了。
所以可以通过在配置文件中将shiro.annotations.enabled属性设置为false。或者是直接在项目的配置中exclude掉ShiroAnnotationProcessorAutoConfiguration。然后再声明AuthorizationAttributeSourceAdvisor即可。
