javascript 注销后页面不安全并单击后退按钮

Page not secured after log out and click back button

提问by Crowie

In my previous employment I was experiencing a well known problem of being unable to prevent the user from being able to navigate the site using the back button after logging out. My technologies include Spring, JavaScript and potentially the Mobile module of the Java AJAX library ZK. Besides navigating using the back button, authorised access worked otherwise. I no longer have access to the application code. The application was a mobile one of which I was not the original author.

在我之前的工作中，我遇到了一个众所周知的问题，即无法阻止用户在注销后使用后退按钮浏览网站。我的技术包括 Spring、JavaScript 和可能的 Java AJAX 库 ZK 的 Mobile 模块。除了使用后退按钮导航之外，授权访问也可以使用其他方式。我无法再访问应用程序代码。该应用程序是一个移动应用程序，其中我不是原作者。

I've tried the following common solutions:

我尝试了以下常见解决方案：

• Have tried adding a WebContentInterceptor(as instructed here)
• Defined my own filter using a combination of this filter questionand this answer about inserting additional filters. Filter code is not executed during debug
• Added RequestMappingHandlerAdapterto set cacheSecondsto 0

• 已尝试添加WebContentInterceptor（按照此处的说明）
• 结合使用此过滤器问题和有关插入其他过滤器的答案定义了我自己的过滤器。调试期间不执行过滤器代码
• 添加RequestMappingHandlerAdapter设置cacheSeconds为 0

We have the following definition in t2-spring-security-context.xml:

我们在 中有以下定义t2-spring-security-context.xml：

<http auto-config="true">
    <intercept-url pattern="/mobile-index*" access="ROLE_ADMIN"/>
    <intercept-url pattern="/t2-metrics*" access="ROLE_ADMIN"/>
    <intercept-url pattern="/t2-monitor*" access="ROLE_ADMIN"/>
    <form-login login-page="/login.jsp" authentication-failure-url="/loginerror.jsp"
                default-target-url="/mobile-index.jsp"/>
    <logout logout-success-url="/login.jsp" invalidate-session="true"/>

</http>

Other details about our implementation:

关于我们实施的其他细节：

• Java methods are called using @RequestMappingfrom JavaScript on a class annotated as @Controller(I.E. t2-metrics.jsp has JS to fire to URL matching request mapping)
• Tried adding security:global-method-securityto application context and role annotation to method
• Have scriptlet code to disable caching to the JSP pages and that did nothing. Also, fired up the application in debug within IntelliJ and a debug point within my define filter is not hit.
• Once they have used the back button to return into the application the user can still navigate around the application.

• Java 方法使用@RequestMappingJavaScript 在注释为@Controller（IE t2-metrics.jsp has JS to fire to URL matching request mapping）的类上调用
• 尝试将security:global-method-security应用程序上下文和角色注释添加到方法
• 使用 scriptlet 代码禁用对 JSP 页面的缓存，但什么也没做。此外，在 IntelliJ 中的调试中启动应用程序，并且未命中我的定义过滤器中的调试点。
• 一旦他们使用后退按钮返回到应用程序，用户仍然可以在应用程序中导航。

My only remaining idea was that the problem involves our client code (JavaScript) or libraries (Incorrect integration with Spring Security) for from the view because debug did not hitting the Spring Security filter chain.

我唯一剩下的想法是问题涉及我们的客户端代码 (JavaScript) 或库（与 Spring Security 的错误集成），因为调试没有命中 Spring Security 过滤器链。

回答by Rajdeep

Use the below code in servlet-context file

在 servlet-context 文件中使用以下代码

    <mvc:interceptors>
        <bean id="webContentInterceptor" class="org.springframework.web.servlet.mvc.WebContentInterceptor">
                <property name="cacheSeconds" value="0"/>
                <property name="useExpiresHeader" value="false"/>
                <property name="useCacheControlHeader" value="true"/>
                <property name="useCacheControlNoStore" value="true"/>
            </bean>     
        </mvc:interceptors>

It will work same as below code in jsp page:

它将与jsp页面中的以下代码相同：

  response.setHeader("pragma", "no-cache");              
  response.setHeader("Cache-control", "no-cache, no-store, must-revalidate");             
  response.setHeader("Expires", "0"); 

回答by Jukka

Are you rendering the views (JSPs) directly?

您是直接渲染视图 (JSP) 吗？

If so, add the no-cache directives directly to the JSPs:

如果是这样，请将 no-cache 指令直接添加到 JSP：

<% response.setHeader("Cache-Control", "no-cache"); %>
...

Another (preferred) option is to prevent direct access to the JSPs and render them through a controller:

另一个（首选）选项是防止直接访问 JSP 并通过控制器呈现它们：

@RequestMapping(value = "/login", method = GET)
public String renderLoginPage() {
    return "login";
}

with this to resolve the view by name (string returned from the controller method):

用这个按名称解析视图（从控制器方法返回的字符串）：

<bean
    id="viewResolver"
    class="org.springframework.web.servlet.view.InternalResourceViewResolver"
    p:prefix="/WEB-INF/views" p:suffix=".jsp"
/>

with /WEB-IBF/views/login.jspas the view.

与/WEB-IBF/views/login.jsp视图。

Using the latterapproach allows you to use the WebContentInterceptorapproach for preventing caching nicely.

使用后一种方法可以让您WebContentInterceptor很好地使用防止缓存的方法。

Also make sure all requests hit the Spring security filter chain.

还要确保所有请求都命中 Spring 安全过滤器链。

回答by smallworld

We don't use Spring security so I am not familiar with all its configuration attributes but if I were you, I would start with looking into browser caching issues. Should be easy to test... (1) force reload of the page after hitting back button, OR (2) after logout, clear out browser cache (not cookies), and then hit the back button. If this results in desired behavior, then next step should be inclusion of HTTP Response Header attributes to control browser caching.

我们不使用 Spring security，所以我不熟悉它的所有配置属性，但如果我是你，我会开始研究浏览器缓存问题。应该很容易测试......（1）在点击后退按钮后强制重新加载页面，或（2）注销后，清除浏览器缓存（不是cookies），然后点击后退按钮。如果这导致了预期的行为，那么下一步应该是包含 HTTP 响应头属性来控制浏览器缓存。

If this is not it, then I wouldn't know what to look for in your Spring security configuration. Hopefully someone else may know the answer.

如果不是这样，那么我不知道要在您的 Spring 安全配置中寻找什么。希望其他人可能知道答案。

EDIT: just found another similar question that confirms browser caching issue part - that question's answer contains a mechanism that they used for setting response headers just in case if that helps you - Spring Security Logout Back Button.

编辑：刚刚发现另一个类似的问题，确认浏览器缓存问题部分 - 该问题的答案包含他们用于设置响应标头的机制，以防万一，如果这对你有帮助 - Spring Security Logout Back Button。

回答by Crowie

Unfortunately, I can no longer return to this code to solve what we had done here that prevented us getting an answer to this question. Its amazing what developers can create to confuse ourselves though.

不幸的是，我无法再回到这段代码来解决我们在这里所做的阻止我们得到这个问题的答案的事情。不过，开发人员可以创造出令人困惑的东西，这真是太神奇了。

Although I think this is the answer (yet to prove), the other answers are useful (and deserve the upvotes), as well as this. The solution I thought at the time was the front-end code which instead of using a Springconstruct such as MVC which Spring Security filterscan manage, we have likelyused Spring's Schedulers(see documentation here) and in some manner bypass the filtertechnology that, as I remember, is essential to implementing Spring Security.

尽管我认为这是答案（尚未证明），但其他答案也很有用（值得点赞），还有这个。我当时认为的解决方案是前端代码，而不是使用Spring Security 过滤器可以管理的Spring构造，例如 MVC ，我们可能使用了 Spring 的调度程序（请参阅此处的文档）并以某种方式绕过过滤器技术我记得，对于实现Spring Security是必不可少的。

I will attempt to post some front-end code that demonstrates the way we call our REST services and proves that we by-pass Spring Security.

我将尝试发布一些前端代码来演示我们调用 REST 服务的方式并证明我们绕过了 Spring Security。

Please feel free to contact me should you disagree.

如果您不同意，请随时与我联系。