I rarely post about development stuff, but this one had me stumped for a couple of hours, so I thought I’d give my solution here.

The issue arises when a user logs out of a protected section of a website. Especially on websites that deal with sensitive data and tools such as banking, you want to make sure that when the user has logged out, they have truly logged out. Whilst there are many forms of eloquently-designed login functionality around, the basic gist is that when you sign in to a website, once your credentials are authenticated they will be stored in the session. So long as the session hasn’t expired, each page load in this protected area of the website should allow you to do whatever it is you’re on the site to do. Logout functionality means clearing and/or abandoning the session. This means that the next time a server receives an HTTP request from that user, it will see that the session is empty and will prompt the user to login again.

That’s all well and good till you come up against caching. One simple way of testing whether this affects your website is to sign in to the protected area, then sign out, then press the back button. If the browser has cached the previous page, it won’t perform a page reload, meaning that no HTTP request is sent to the server, so no authentication check is made as to whether the user should be seeing that page. Therefore, any solution to this must be dealt with on the client-side.

After searching for various possible solutions, I came across this article here which is wonderfully succinct and lists the pros/cons of each approach. His final suggestion for solving the problem is the one I’d recommend. It essentially involves creating a web method in your logout page which checks to see whether or not the user is still authenticated, then uses jQuery to send an Ajax message to that method and, if the answer is no, you redirect the user to the login page. This is undoubtedly the most cross-browser-friendly solution, although for some reason it didn’t seem to work in Firefox.

For whatever reason, in FF the JavaScript state is maintained, so in addition to no page reload, the document ready event in jQuery does not fire on a cached page. Oddly, the official Mozilla documentation insists that a page reload can be forced if you use the Cache-Control: no-cache, no-store directive in the headers, but this didn’t seem to work. The solution did work, however, in Chrome and IE.

The way I finally got it to work is by making use of Firefox’s pageshow event. Whilst the document ready method isn’t fired when a cached page is loaded, pageshow always is. As the JavaScript state is preserved, you can add the handler to this event within the document.ready function (which will be preserved for when the back button is clicked). The line of code is as follows:

window.addEventListener(‘pageshow’, YourCheckSessionFunctionName, false);

This way, if the user clicks back, within a split second the redirect kicks in and they’re faced with the login screen. Job done. 🙂

Categories: Uncategorized

1 thought on “Preventing the browser-back-button from revealing user information”

Nathaniel · November 7, 2013 at 10:27 am

This is really helpful, as i am facing the same problem at the moment. I will try to implement and let you know my results.

Thanks,

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts

Uncategorized

Why the Lib Dems should vote for all-women shortlists – from somebody who used to oppose them

(…Or how I stopped worrying and learnt to acknowledge my privilege) As a Lib Dem, I was vociferously against AWS and tokenism in general, so much so that I joined with others to oppose it Read more…

Uncategorized

A depression-suffering Labour member writes: Ken’s “apology” is not good enough

I’ve suffered from depression for about two years now. I have a similar story to most – some days are better than others, but the treatment does wonders and helps me identify triggers that are Read more…

Uncategorized

Hackathons: they’re fun, but they need to change

I’m very lucky to have a (current) winning streak when it comes to Hackathons. At Intertech LGBT’s hackathon in 2014, we were joint winners of the first prize and a couple of weeks ago, we Read more…