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.
I've tried the following mon solutions:
- Have tried adding a
WebContentInterceptor(as instructed here ) - Defined my own filter using a bination of this filter question and this answer about inserting additional filters. Filter code is not executed during debug
- Added
RequestMappingHandlerAdapterto setcacheSecondsto 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 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.
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.
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.
I've tried the following mon solutions:
- Have tried adding a
WebContentInterceptor(as instructed here ) - Defined my own filter using a bination of this filter question and this answer about inserting additional filters. Filter code is not executed during debug
- Added
RequestMappingHandlerAdapterto setcacheSecondsto 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 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.
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.
Share Improve this question edited May 23, 2017 at 11:55 CommunityBot 11 silver badge asked May 29, 2013 at 16:46 CrowieCrowie 3,2727 gold badges30 silver badges50 bronze badges 04 Answers
Reset to default 9Use the below code in 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 same as below code in jsp page:
response.setHeader("pragma", "no-cache");
response.setHeader("Cache-control", "no-cache, no-store, must-revalidate");
response.setHeader("Expires", "0");
Are you rendering the views (JSPs) directly?
If so, add the no-cache directives directly to the JSPs:
<% response.setHeader("Cache-Control", "no-cache"); %>
...
Another (preferred) option is to prevent direct access to the JSPs and render them through a controller:
@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.jsp as the view.
Using the latter approach allows you to use the WebContentInterceptor approach for preventing caching nicely.
Also make sure all requests hit the Spring security filter chain.
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.
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.
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.
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 Spring construct such as MVC which Spring Security filters can manage, we have likely used Spring's Schedulers (see documentation here) and in some manner bypass the filter technology that, as I remember, is essential to implementing 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.
Please feel free to contact me should you disagree.