shiro如何放行ajax请求，shiro放行ajax请求配置

在Spring Security与Apache Shiro集成的开发环境中，许多开发者常遇到一个痛点：前端发起的AJAX异步请求被Shiro拦截器错误地重定向到登录页面，导致JSON响应被HTML登录页取代，前端无法正确解析错误状态，核心上文小编总结非常明确：Shiro默认拦截所有请求，包括AJAX请求，要实现AJAX请求的放行或优雅处理，不能简单地“放行”所有AJAX，而应通过自定义Shiro过滤器，识别请求头中的X-Requested-With: XMLHttpRequest特征，并在未登录时返回特定的HTTP状态码（如401）及JSON格式的错误信息，而非执行重定向操作。 这一方案既保证了安全性,又提升了前后端交互的体验。

深入剖析Shiro拦截AJAX请求的根本原因

Shiro的核心安全机制依赖于FilterChainResolver，当请求进入时，Shiro会匹配配置的filterChainDefinitionMap，默认情况下，如果配置了/** = authc，意味着所有路径都需要认证，当用户未登录且访问受保护资源时，Shiro的FormAuthenticationFilter会调用executeLogin失败后的默认行为，即调用saveRequestAndRedirectToLogin方法，该方法执行的是response.sendRedirect(),这是一个同步的重定向指令。

对于传统的表单提交，浏览器会跟随重定向跳转到登录页，用户体验正常，但对于AJAX请求，浏览器不会自动处理重定向到登录页的HTML内容，而是将其作为响应体接收，由于响应头中通常包含Content-Type: text/html，前端JavaScript代码尝试解析JSON时必然失败，导致业务逻辑中断，问题的关键不在于“放行”，而在于“区分对待”：区分普通页面请求和异步API请求。

专业解决方案：自定义Shiro过滤器实现精准拦截

要实现AJAX请求的友好处理，最佳实践是继承Shiro的FormAuthenticationFilter或AuthorizationFilter，重写其拦截逻辑,以下是具体的实施步骤和代码逻辑解析。

识别AJAX请求

在自定义过滤器中，首先需要判断当前请求是否为AJAX请求，这通常通过检查HTTP请求头中的X-Requested-With字段来实现，如果该字段的值为XMLHttpRequest,则判定为AJAX请求。

private boolean isAjaxRequest(ServletRequest request) {
    HttpServletRequest httpRequest = (HttpServletRequest) request;
    return "XMLHttpRequest".equals(httpRequest.getHeader("X-Requested-With"));
}

未认证时的差异化处理

当用户未通过认证时，普通请求应重定向到登录页，而AJAX请求应返回401状态码及JSON错误信息，我们需要重写isAccessAllowed或onAccessDenied方法。

在onAccessDenied方法中,加入如下逻辑：

@Override
protected boolean onAccessDenied(ServletRequest request, ServletResponse response) throws Exception {
    if (isAjaxRequest(request)) {
        // 针对AJAX请求：返回401状态码和JSON格式的错误信息
        HttpServletResponse httpResponse = (HttpServletResponse) response;
        httpResponse.setStatus(HttpStatus.UNAUTHORIZED.value());
        httpResponse.setContentType("application/json;charset=UTF-8");
        PrintWriter writer = httpResponse.getWriter();
        writer.write("{\"code\":401,\"msg\":\"请先登录\"}");
        writer.flush();
        writer.close();
        return false; // 阻止继续执行链
    } else {
        // 针对普通请求：执行默认的重定向逻辑
        saveRequestAndRedirectToLogin(request, response);
        return false;
    }
}

配置Shiro Filter Chain

在Shiro的配置类中，将自定义的过滤器注册到Spring容器，并在filterChainDefinitionMap中将其应用到特定的API路径或全局路径，将自定义过滤器命名为ajaxAuthc,并在配置中指定：

map.put("/api/**", "ajaxAuthc");

这样，所有以/api/开头的请求都会经过自定义过滤器的处理,而其他静态资源或页面请求则遵循默认规则。

前端配合与最佳实践

后端处理完成后，前端也需要配合进行状态码监听，在jQuery或Axios等主流HTTP客户端中，配置全局拦截器，当捕获到401状态码时，不要直接报错，而是通过window.location.href将用户重定向到登录页，或者弹出模态框提示用户重新登录，这种前后端协同的方案,确保了系统在安全性与用户体验之间的平衡。

对于涉及敏感操作的AJAX请求，建议结合Token机制（如JWT）而非仅依赖Session，Shiro同样支持JWT插件，通过自定义Realm验证Token，可以彻底摆脱Session重定向的困扰，实现无状态的安全控制,这是现代微服务架构下的更优解。

相关问答

Q1: 如果我的项目同时存在页面请求和API请求，如何配置Shiro才能同时兼容两者？

A: 不要使用单一的/** = authc配置，应采用路径前缀区分，将页面相关的路径（如/pages/**）配置为authc（默认过滤器），将API接口路径（如/api/**）配置为自定义的ajaxAuthc过滤器，这样，Shiro会根据URL前缀自动路由到不同的处理逻辑,互不干扰。

Q2: 使用自定义过滤器后，为什么有时仍然会出现重定向？

A: 这通常是因为过滤器链的顺序问题或配置遗漏，请检查filterChainDefinitionMap中，自定义过滤器是否被更通用的规则（如/** = anon或/** = authc）覆盖，确保自定义过滤器在映射中处于更优先或更具体的位置，检查是否在某些Controller方法上使用了@RequiresAuthentication注解，这可能会绕过Filter层面的逻辑，导致行为不一致，建议统一通过Filter链进行权限控制，或在Controller层仅做业务逻辑,不做安全拦截。

互动

你在实际开发中是否遇到过Shiro拦截AJAX请求导致的尴尬局面？你是如何解决的？欢迎在评论区分享你的踩坑经验和优化方案,让我们一起构建更健壮的安全架构。