web-dev-qa-db-ja.com

Wp_logout_url()はセッションを破棄しますか? (質問をログアウトする)

私は自分のサイトからユーザーをログアウトさせることに関してばかげた問題を抱えています。基本的に、クライアントには機密データがあり、wp_logout_urlを呼び出すと別のURLにリダイレクトします。これで問題はありませんが、ブラウザはページをキャッシュし、 _ back _ を押すと表示されます。

これを止める方法はありますか、それとも解決できない問題ではありませんか。

このサイトはフロントエンドのログインフォームで保護されているので/ wp-adminではありません。

4
SMacFadyen

これは驚くべきことでも珍しいことでもありません。ブラウザがどのように機能するか、ページがキャッシュされること、そしてブラウザ履歴の一部であることです。これはWordPressに固有のものではありませんが、多くのWebアプリケーションがあります。

解決策を提供するためのさまざまなアプローチもあります。 1つの場合(あまり良い解決策ではありません)、 ブラウザの履歴をクリアする

他の人のために - Twitterのように、特別なキャッシュヘッダを送信する。 RFC をチェックしてください。

Webページがすべてのブラウザでキャッシュされていないことを確認する も良い出発点です。

あなたは、機密情報を調べることになるログインユーザのためのアンチキャッシュヘッダを追加することができます。機密情報を含むすべてのページは、ブラウザがこれらのヘッダに従い、ログアウト後に戻るときに再検証できるように、これらのヘッダを持つ必要があります。 (ログインしていない)他のみんなにとってブラウザのキャッシュを利用可能にしておくことは、一般的には良い考えです。

WordPressでヘッダーを設定するis_user_logged_in または user_can に対しては、かなり簡単です。

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

上記をテストしたところ、少なくともChromeでは動作するようです。お役に立てれば。大きな質問ですが、WordPressが少なくともDashboardページで再認証を強制しないのはなぜだろうか。

一般的な管理者問題に対処するためのチケットを作成しました: http://core.trac.wordpress.org/ticket/21938

3
soulseekah

Wordpressはサーバーサイドのセッションストレージをまったく使用しません - クッキー(クライアントサイドのセッションストレージ)のみを使用します。

そして、あなたはウェブブラウザの歴史にアクセスする機会がありません...

キャッシングを無効にすること(上記のように)は有望に思えます - しかし確かにもっと多くのリソースを必要とします。

そうではないでしょう - 単にページ速度が確かに悪くなるからです。

0
Martin Zeitler