RequestCacheAwareFilter过滤器对应的类路径为
org.springframework.security.web.savedrequest.RequestCacheAwareFilter
这个filter的用途官方解释是
用于用户登录成功后,重新恢复因为登录被打断的请求
这个解释也有几点需要说明
被打算的请求:简单点说就是出现了AuthenticationException、AccessDeniedException两类异常
重新恢复:既然能够恢复,那肯定请求信息被保存到cache中了
首先看被打断请求是如何保存到cache中的
实际上,上一篇的ExceptionTranslationFilter分析已经提到了
requestCache.saveRequest(request, response)
是的,如果出现AuthenticationException或者是匿名登录的抛出了AccessDeniedException,都会把当前request保存到cache中。这里的cache是HttpSessionRequestCache,接着看HttpSessionRequestCache的saveRequest方法
public void saveRequest(HttpServletRequest request, HttpServletResponse response) {
//由于构造HttpSessionRequestCache的bean时,没有设置justUseSavedRequestOnGet属性,所以该属性为默认值false。
if (!justUseSavedRequestOnGet || "GET".equals(request.getMethod())) {
//构造DefaultSavedRequest,并且设置到session中
DefaultSavedRequest savedRequest = new DefaultSavedRequest(request, portResolver);
if (createSessionAllowed || request.getSession(false) != null) {
request.getSession().setAttribute(DefaultSavedRequest.SPRING_SECURITY_SAVED_REQUEST_KEY, savedRequest);
}
}
}
这里应该知道,实际上被打断的请求被封装成DefaultSavedRequest对象保存到session中了
分析完保存被打断的请求,接着就分析如何恢复被打断的请求了。RequestCacheAwareFilter过滤器就是完成恢复的工作。看doFilter方法
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
//根据当前session取出DefaultSavedRequest,如果有被打断的请求,就把当前请求与被打断请求做匹配。如果匹配成功,对当前请求封装,再传递到下一个过滤器
HttpServletRequest wrappedSavedRequest =
requestCache.getMatchingRequest((HttpServletRequest)request, (HttpServletResponse)response);
chain.doFilter(wrappedSavedRequest == null ? request : wrappedSavedRequest, response);
}
继续看HttpSessionRequestCache处理过程
//从当前session中提取DefaultSavedRequest对象
public SavedRequest getRequest(HttpServletRequest currentRequest, HttpServletResponse response) {
HttpSession session = currentRequest.getSession(false);
if (session != null) {
return (DefaultSavedRequest) session.getAttribute(DefaultSavedRequest.SPRING_SECURITY_SAVED_REQUEST_KEY);
}
return null;
}
//清除被打断请求
public void removeRequest(HttpServletRequest currentRequest, HttpServletResponse response) {
HttpSession session = currentRequest.getSession(false);
if (session != null) {
logger.debug("Removing DefaultSavedRequest from session if present");
session.removeAttribute(DefaultSavedRequest.SPRING_SECURITY_SAVED_REQUEST_KEY);
}
}
//请求匹配
public HttpServletRequest getMatchingRequest(HttpServletRequest request, HttpServletResponse response) {
DefaultSavedRequest saved = (DefaultSavedRequest) getRequest(request, response);
//如果没有被打断请求,直接返回null,不做处理
if (saved == null) {
return null;
}
//如果当前请求与被打断请求不匹配,直接返回null,不做处理
if (!saved.doesRequestMatch(request, portResolver)) {
logger.debug("saved request doesn't match");
return null;
}
//清除被打断请求
removeRequest(request, response);
//重新包装当前请求为被打断请求的各项信息
return new SavedRequestAwareWrapper(saved, request);
}
接着分析doesRequestMatch方法,看请求是如何匹配的
//就是比较request与cache中被打断请求的各项信息是否相同
//这里有个疑惑(由于被打断请求包括POST、GET提交方式的,而这里要求必须为GET方式的请求才会匹配成功)
public boolean doesRequestMatch(HttpServletRequest request, PortResolver portResolver) {
if (!propertyEquals("pathInfo", this.pathInfo, request.getPathInfo())) {
return false;
}
if (!propertyEquals("queryString", this.queryString, request.getQueryString())) {
return false;
}
if (!propertyEquals("requestURI", this.requestURI, request.getRequestURI())) {
return false;
}
if (!"GET".equals(request.getMethod()) && "GET".equals(method)) {
// A save GET should not match an incoming non-GET method
return false;
}
if (!propertyEquals("serverPort", new Integer(this.serverPort), new Integer(portResolver.getServerPort(request))))
{
return false;
}
if (!propertyEquals("requestURL", this.requestURL, request.getRequestURL().toString())) {
return false;
}
if (!propertyEquals("scheme", this.scheme, request.getScheme())) {
return false;
}
if (!propertyEquals("serverName", this.serverName, request.getServerName())) {
return false;
}
if (!propertyEquals("contextPath", this.contextPath, request.getContextPath())) {
return false;
}
if (!propertyEquals("servletPath", this.servletPath, request.getServletPath())) {
return false;
}
return true;
}
这里为何对POST请求匹配不成功,目前还不知道具体设计思路。知道后会进行补充
分享到:
相关推荐
### Spring Security 源码分析知识...以上内容涵盖了 Spring Security 3 的源码分析中几个关键点的具体内容。通过对这些内容的深入学习和理解,可以更好地掌握 Spring Security 的工作原理及其在实际项目中的应用技巧。
通过这些源码分析,我们可以了解到Spring Security是如何在背后工作,保护应用程序免受未经授权的访问。理解这些组件的工作原理对于定制和优化安全配置至关重要,同时也有助于开发者解决潜在的安全问题。
6. **源码分析**: Spring Security的源码是开源的,你可以深入研究其内部工作原理,了解每个组件是如何协同工作的。这将帮助你更好地理解和定制这个框架。 7. **工具**: - Spring Security的官方文档和教程是...
通过学习和分析这些源代码,你可以深入了解Spring Security的工作原理,以及如何将其集成到你的应用程序中以实现安全控制。对于开发人员来说,理解这些核心概念和组件非常重要,因为它们构成了Spring Security强大...
基于transUnet和swinUnet的医学图像分割项目实验对比,包含完整代码,可以一键运行。评估指标包括dice、iou、recall、precision等
,stm32f030无感foc方案,资料包括原理图,pcb,源程序,观测器参数,电流环参数计算表格。
分布式电源DG选址定容优化及帕累托最优解集的粒子群算法研究,多目标粒子群算法 分布式电源 DG 定容选址 网损 成本 电压偏差 通过分布式能源的选址定容确定得到帕累托最优解集,然后选择最优值进行分析,程序采用改进粒子群算法, ,核心关键词:多目标粒子群算法; 分布式电源选址定容; 网损; 成本; 电压偏差; 帕累托最优解集。,改进粒子群算法在分布式电源选址定容中的应用:优化网损与成本,考虑电压偏差
交变磁场感应材料对沥青路面温度影响的研究,交变磁场下含感应材料沥青路面温度 ,交变磁场; 感应材料; 沥青路面; 温度; 变化; 加热效率,交变磁场对含感应材料沥青路面温度的影响研究
基于Comsol模拟的三层顶板随机裂隙浆液扩散模型:考虑重力影响的瞬态扩散规律分析,Comsol模拟,考虑三层顶板包含随机裂隙的浆液扩散模型,考虑浆液重力的影响,模型采用的DFN插件建立随机裂隙,采用达西定律模块中的储水模型为控制方程,分析不同注浆压力条件下的浆液扩散规律,建立瞬态模型 ,Comsol模拟; 随机裂隙浆液扩散模型; 浆液重力影响; DFN插件; 达西定律模块储水模型; 注浆压力条件; 浆液扩散规律; 瞬态模型,Comsol浆液扩散模型:随机裂隙下考虑重力的瞬态扩散分析
对于Sqlserver数据库只是提供了简单的图形化的导出导入工具,在实际的开发和生产环境不太可能让用户在图形化的界面选择移行的对象,进行移行。 我们在数据库的移行中也遇到这种问题,需要提供一个工具给客户使用。所以我们开发了针对SQLServer数据库的cmd形式导入导出的工具。在长期的实践中不断完善,基本可以实现Oracle的导入导出工具的80%的功能,也比较的稳定。有需要的可以下载使用,也可以提供定制化的服务
内容概要:本文介绍了DeepSeek模型在不同平台上部署的方法。首先阐述了基于Ollama的本地部署,包括Ollama的安装、模型拉取以及交互模式的使用。接着讲解了DeepSeek在移动设备(iOS和Android)上的部署细节:iPhone需要通过Safari安装快捷指令,配置API Key并通过快捷指令测试运行;Android则借助Termux安装必要组件,并手动搭建Ollama环境以加载和测试模型。最后详细叙述了基于Open WebUI部署的方式,涉及Ollama、Docker Desktop及Open WebUI的安装流程及其之间的配合使用来最终达成模型的成功部署。 适用人群:面向有兴趣了解或者实际操作DeepSeek模型跨平台部署的技术开发者、研究人员以及AI爱好者。 使用场景及目标:适用于希望利用DeepSeek模型快速构建本地化应用程序、开展实验研究的用户;具体目标为掌握DeepSeek模型在桌面系统(如Linux、macOS、Windows)、iOS和Android智能手机以及云端WebUI界面上的不同部署手段和技术。 其他说明:对于每种类型的部署都提供了详细的步骤指导,旨在帮助使用者顺利完成所需工具和环境的安装,并确保模型能够正常工作。文中给出的具体链接和命令行脚本,有助于降低初次接触者的上手难度,提升部署效率和成功率。此外,还强调了一些重要的配置注意事项,例如正确输入API key以及对Ollama的初始化检查等。
,FOC 无感 混合磁链观测器 电机控制 代码 PMSM MiniDD(直驱)电机变频无感程序,包含偏心,重量,共振等感知算法,所有算法都不基于库函数,MCU底层配置完全手写
nodejs010-nodejs-cmd-shim-1.1.0-4.1.el6.centos.alt.noarch.rpm
基于S7-200 PLC的交通灯倒计时控制及组态王界面实现原理图解析,S7-200 PLC和组态王交通灯带倒计时控制 923 47 带解释的梯形图接线图原理图图纸,io分配,组态画面 ,S7-200 PLC; 交通灯; 倒计时控制; 组态王; 梯形图接线图; IO分配; 组态画面,"S7-200 PLC与组态王交通灯倒计时控制:梯形图原理及IO分配详解"
西门子四轴卧加后处理系统:828D至840D兼容,四轴联动高效加工解决方案,支持图档处理及试看程序。,西门子四轴卧加后处理,支持828D~840D系统,支持四轴联动,可制制,看清楚联系,可提供图档处理试看程序 ,核心关键词:西门子四轴卧加后处理; 828D~840D系统支持; 四轴联动; 制程; 联系; 图档处理试看程序。,西门子四轴卧加后处理程序,支持多种系统与四轴联动
FPGA篮球赛事24秒倒计时计时器设计与实现(基于Verilog与VHDLL的优化对比),基于fpga篮球倒计时24s。 verilog和vhdl两个版本 ,基于FPGA篮球倒计时24s; Verilog版本; VHDL版本,FPGA篮球比赛倒计时24秒系统:Verilog与VHDL双版本实现
论生成式AI在大学生学习中的应用与伦理问题.pdf
免费JAVA毕业设计 2024成品源码+论文+数据库+启动教程 启动教程:https://www.bilibili.com/video/BV1SzbFe7EGZ 项目讲解视频:https://www.bilibili.com/video/BV1Tb421n72S 二次开发教程:https://www.bilibili.com/video/BV18i421i7Dx
"S7-200plc与MCGS智能居家控制系统的深度融合:组态画面、IO分配与梯形图接线图原理详解",No.63 S7-200plc和 MCGS智能居家控制系统组态 带解释的梯形图接线图原理图图纸,io分配,组态画面 ,核心关键词:S7-200plc; MCGS智能居家控制系统; 梯形图接线图原理图; io分配; 组态画面。,"S7-200 PLC与MCGS智能居家系统组态及梯形图原理图解析"
方便暖通工程师及板换用户了解艾齐尔板式换热器选型计算,免费使用。