CODEWITHSUNDEEP
javascriptspringspring-mvcmobilespring-security
Crowie
Crowie

Reputation: 3272

Page not secured after log out and click back button

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 common solutions:


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:

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.

Upvotes: 6

Views: 12070

Answers (4)

Crowie
Crowie

Reputation: 3272

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.

Upvotes: 0

Rajdeep
Rajdeep

Reputation: 270

Use 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");

Upvotes: 9

Jukka
Jukka

Reputation: 4663

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.

Upvotes: 2

smallworld
smallworld

Reputation: 930

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.

Upvotes: 0

Related Questions