5

I have a ridiculous issue with logging users out of my site. Basically, the client has sensitive data and when I call wp_logout_url I redirect to another url. That's fine, but the browser caches the page and can be seen by pressing BACK.

Is there ANY way I can stop this happening, or is it a non-issue that cannot be solved?

The site is protected by a login form on the front end, so it's not /wp-admin.

Improve this question
3
  • Where have you seen $_SESSION used in core?
    – kaiser
    Sep 19, 2012 at 14:19
  • I'm sorry I don't understand, any chance you can elaborate?
    – SMacFadyen
    Sep 19, 2012 at 14:40
  • 2
    You asked (in the title) "(...) destroy a session".
    – kaiser
    Sep 19, 2012 at 15:20

2 Answers 2

Reset to default
4

This is not surprising or uncommon, it's how browsers work, the pages are cached and are part of the browser history. This is not specific to WordPress but many web applications out there.

There are also different approaches to providing a solution. For one (not very good solution), clearing the browser history.

For another - sending in special cache headers, like Twitter does. Check out the RFC for specifics.

Making sure a web page is not cached across all browsers is a good starting point, too.

You can add the anti-cache headers for logged in users that will look at sensitive information. All pages with sensitive information would have to have these headers so that browsers can obey them and re-validate upon pressing back after logging out. For everyone else (not logged in) keep browser caching available, which is generally a good idea.

Setting headers in WordPress, against is_user_logged_in or user_can is quite straight-forward.

add_action( 'init', function() {
    /* Force no-cache headers on *ALL* front pages and in *ALL* cases */
    /* Proof of concept, do not use */
    header( 'Cache-Control: no-cache, no-store, must-revalidate' );
    header( 'Pragma: no-cache' );
    header( 'Expires: 0' );
    /* Do same for admin_init to get dashboard to not cache */
} );

Tested the above and it appears to work, at least in Chrome. Hope this helps. Great question, I wonder why WordPress doesn't force reauthentication on at least the Dashboard pages.

Created ticket to address general Administrator issue: http://core.trac.wordpress.org/ticket/21938

Improve this answer
5
  • 1
    +1, I'd do +x if I could. - should be a quick plugin in the meanwhile. Just a note, if I didn't missunderstand this: "Do same for admin_init". Normally the init hook is present on both the front as well as the admin side.
    – kaiser
    Sep 20, 2012 at 11:59
  • 1
    Thanks, @kaiser, I'm a bit rusty on my WordPress-fu, so you're probably right, init should handle both cases - front-end and back-end. There's also a nocache_headers hook available for places where browser caching was not meant to be, which includes all of the Dashboard.
    – soulseekah
    Sep 20, 2012 at 13:31
  • Ah, nice! From a brief look: The wp class and its main function already sends no-cache headers for logged in users and for 404s during send_headers. You could intercept them on the wp_headers-hook. Guess this could be investigated much further...
    – kaiser
    Sep 20, 2012 at 13:38
  • 2
    @kaiser, as stated in the ticket core.trac.wordpress.org/ticket/21938 the missing bit is the "no-store" directive, which most browsers interpret as "OK, I won't cache this page in the history". Also I'm trying it with init and it's not working, as if the headers are overwritten after init.
    – soulseekah
    Sep 20, 2012 at 13:40
  • 1
    Just added this word-for-word to a member section page template I am using in the Genesis framework. Worked like a charm! The only changes (ok it wasn't completely word for word) is that I couldn't use an anonymous function so I had to separate that out. And I put it in 'genesis_before' so it would work with the genesis framework. Not sure if Genesis will allow you to hook to init. I tried on somethng else and couldn't get it to work. but genesis_before works fine.
    – user34121
    Jun 14, 2013 at 15:10
0

Wordpress does not use server-side session storage at all - only cookies (client-side session storage).

And you have no chance to access the web-browser's history...

To disable caching (as stated above) sounds promising - but needs more resources for sure.

Wouldn't do so - simply because the page-speed would suffer for sure.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.