web-dev-qa-db-fra.com

Wp_logout_url () détruit-il une session? (Question de déconnexion)

J'ai un problème ridicule à déconnecter les utilisateurs de mon site. En gros, le client a des données sensibles et lorsque j'appelle wp_logout_url, je le redirige vers une autre URL. C'est bien, mais le navigateur met la page en cache et peut être visualisé en appuyant surBACK.

Y at-il AUCUN moyen d’empêcher que cela se produise, ou s’agit-il d’un problème qui ne peut pas être résolu?

Le site est protégé par un formulaire de connexion au début, ce n’est donc pas/wp-admin.

loginsession
4
SMacFadyen

Ce n'est pas surprenant ou peu commun, c'est la façon dont les navigateurs fonctionnent, les pages sont mises en cache et font partie de l'historique du navigateur. Ce n'est pas spécifique à WordPress mais à de nombreuses applications Web.

Il existe également différentes approches pour apporter une solution. Pour un (pas très bonne solution), effacer l'historique du navigateur .

D'autre part, envoyer des en-têtes de cache spéciaux, comme le fait Twitter. Découvrez le RFC pour plus de détails.

S'assurer qu'une page Web n'est pas mise en cache sur tous les navigateurs est également un bon point de départ.

Vous pouvez ajouter les en-têtes anti-cache pour les utilisateurs connectés qui examineront les informations sensibles. Toutes les pages contenant des informations sensibles devraient avoir ces en-têtes afin que les navigateurs puissent les respecter et les valider de nouveau après la fermeture de session après la déconnexion. Pour tous les autres (non connectés), maintenez la mise en cache du navigateur disponible, ce qui est généralement une bonne idée.

La définition des en-têtes dans WordPress , contre is_user_logged_in ou user_can est assez simple.

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 */
} );

Testé ce qui précède et cela semble fonctionner, du moins sous Chrome. J'espère que cela t'aides. Bonne question, je me demande pourquoi WordPress n'impose pas de nouvelle authentification au moins sur les pages du tableau de bord.

Création du ticket pour résoudre le problème général de l'administrateur: http://core.trac.wordpress.org/ticket/21938

3
soulseekah

Wordpress n'utilise pas du tout le stockage de session côté serveur, mais uniquement des cookies (stockage de session côté client).

Et vous n'avez aucune chance d'accéder à l'historique du navigateur Web ...

Désactiver la mise en cache (comme indiqué ci-dessus) semble prometteur - mais nécessite certainement plus de ressources.

Ne le ferait pas - simplement parce que la vitesse de la page en souffrirait à coup sûr.

0
Martin Zeitler