The page is not protected after logging out and click the "Back" button

Question

In my previous work, I encountered a well-known problem of the inability of the user not to navigate the site using the "Back" button after logging out. My technologies include Spring, JavaScript, and possibly the Java AJAX ZK mobile library module. In addition to navigating with the back button, authorized access worked differently. I no longer have access to the application code. The application was mobile, from which I was not the original author.

I have tried the following general solutions:

• Tried to add WebContentInterceptor (as indicated here )
• Define your own filter using a combination of this filter question and this answer about inserting additional filters . Filter code is not executed during debugging
• Added RequestMappingHandlerAdapter to set cacheSeconds to 0

. We have the following definition in 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 information about our implementation:

• Java methods are invoked using @RequestMapping from JavaScript in a class annotated as @Controller (IE t2-metrics.jsp has JS for triggering URL mapping requests matching)
• Tried to add security:global-method-security to the application context and role annotations to the method
• Ask the script code to disable caching on JSP pages and did nothing. In addition, the application was launched during debugging in IntelliJ, and the debug point did not appear in my definition filter.
• After they used the back button to return to the application, the user can still navigate the application.

My only remaining idea was that the problem was with our client code (JavaScript) or libraries (incorrect integration with Spring Security) from the view, since debugging did not fall into the Spring filter chain.

Answer 1

Use the code below in the servlet context file

  <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 just like the code below on the jsp page:

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

Answer 2

Do you visualize views (JSPs) directly?

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

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

Another (preferred) option is to prevent direct access to the JSP and execute them through the controller:

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

with this, to allow the presentation 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.jsp as a view.

Using the latter approach, you can use the WebContentInterceptor approach to prevent caching.

Also, make sure all requests fall into the Spring Security Filter Chain.

Answer 3

We do not use Spring security, so I am not familiar with all of its configuration attributes, but if I were you, I would start to study browser caching issues. It should be easy to check ... (1) force the page to reload after pressing the return button, OR (2) after logging out, clear the browser cache (not cookies), and then click the "Back" button. If this leads to the desired behavior, then the next step should be to include the HTTP response header attributes to control browser caching.

If this is not the case, I do not know what to look for in your Spring security configuration. Hope someone else can know the answer.

EDIT: just found another similar question that confirms part of the browser caching problem - this question contains a mechanism that they used to set response headers in case this helps you - Spring Security Logout button .

Answer 4

Unfortunately, I can no longer return to this code to decide what we did here, which prevented us from getting an answer to this question. Its amazing what developers can create to confuse themselves, though.

Although I think this is the answer (not yet proven), the other answers are useful (and deserve attention) as well as this. At that time, the solution I thought was front-end code, which, instead of using the Spring constructor, such as MVC, which can control Spring security filters, we most likely used Spring schedulers (see the documentation here ) and somehow work around filtering technology, which, as I recall, is important for implementing Spring Security.

I will try to publish some external code that demonstrates the way we call our REST services and proves that we circumvent Spring Security.

Please feel free to contact me if you do not agree.