Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Where have you seen $_SESSION used in core? –  kaiser Sep 19 '12 at 14:19
    
I'm sorry I don't understand, any chance you can elaborate? –  SMacFadyen Sep 19 '12 at 14:40
2  
You asked (in the title) "(...) destroy a session". –  kaiser Sep 19 '12 at 15:20
    
Well, thanks for your useful comment. –  SMacFadyen Sep 20 '12 at 8:54

2 Answers 2

up vote 2 down vote accepted

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

share|improve this answer
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 '12 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 '12 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 '12 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 '12 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 '13 at 15:10

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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