Leave a Reply

2 comments

  1. 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

  2. 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.