While developing any web application most of us have seen a common glitch where by hitting ‘Back’ button of the browser after successful sign-out, we would still get to see the pages which should only be visible if our session is alive.
The scenario I am referring to is the one where we have already handled all the cases in the server side code for redirecting the user to login page if their session does not exist while making an attempt to see the authenticated content.
The problem is caused by the history maintained by the browser itself. The Back button of the modern browsers fetches the previously navigated page from the history instead of fetching it from the server in order to optimize the response delay. Since the page is not coming from the server we cannot have the authentication logic to work and perform a redirection.
To fix this issue we may add HTTP headers in the request responsible for serving the page that tells the browser to get these pages directly from the server every time instead of the cache or history of browser.
We will be using filter API in play framework to make changes in every request. To know more about the filters and how they are used, read this documentation : Play 2.4 filter API
Custom filter that would add the http headers in each request
Add this line in the application.conf file of your play-application
Sample controller Actions and the flow that would be required for this to work
That’s all there is to fix the issue of “back-button-after-logout” panic, in play-application. This fix is not gonna require any special java-script to disable the redirection and we won’t have to disable the Back button’s functionality.
But as always there is a trade off in this scenario as well, we may see some decrease in performance if the application is not very dynamic i.e. If you want to cache the whole HTML page within the browser cache. Also this fix is reliable only for the modern browsers and may not support legacy HTTP 1.0 on all previous versions.
Note: we have tested this fix on chrome 47.0.2526.111 (64-bit), firefox 37.0 and safari 9.0
KNOW ABOUT THE HTTP HEADERS USED :