web-dev-qa-db-ja.com

セッションタイムアウトを増やす

したがって、私はDrupal 8.で完了する方法に困惑しつつあります。

要件を簡略化するつもりです。私には2つの役割があります。それらは本質的に相互に排他的です。それらを「内部」と「クライアント」と呼びましょう。

リクエストはクライアントに無期限にログインすることです...それをyearsと呼びましょう。内部ユーザーは、短時間、たとえば1日、またはセッションだけでログインする必要があります。 （注：これらの要件は作成せず、コーディングするだけです... haha​​）

Drupalログインについての私の理解は、これを制御する2つのことが実際にあるということです...ユーザーのcookie存続期間と（サーバー上の）セッション存続期間があります。 Cookieの有効期間は1週間ですが、セッションの有効期間は1日です。ユーザーは基本的に1日後にログアウトされます。b/ cユーザーのCookieは1日後に存在しないセッションと一致します...そうですか？

だから上限から始めないといけないと思います。ユーザーを1年間ログインさせたい場合は、サーバーセッションを1年間にする必要があります。私の質問の1つは、サーバーセッションを1年に設定することのリスク/欠点/その他は何ですか？サーバーが1か月に5万回アクセスするとします。 1年ではなく、2年にしたい場合はどうなりますか？サーバーセッションの上限を決定するガイドが見つからないようです。そのセッションをクリアできる要因がたくさんあるようです...

さて、上記は1つの質問です...サーバーセッションを設定できると仮定して、ユーザーの役割に基づいてCookieの有効期間をどのように訪問できますか？この設定を変更することは不可能である可能性があるようになり、ある種のルートサブスクライバーとカスタムCookieを実行し、内部ユーザーを検出して、ログアウトしたときにログアウトする必要がある場合がありますログインが長すぎます...

どんな助けでも大歓迎です...

8userssessionscookies
5
Dave

過去にDrupal 7で少しカスタムコードを使用してこの目標を達成しました。

  1. Cookieの有効期間とサーバーセッションのタイムアウトを2つの数値の大きい方に設定します。あなたの場合は2年だと思います。
  2. 古いセッションを見つけて削除するカスタムスクリプト（drushなど）を記述します。

アイテム＃2の場合、これは、存続期間が短い内部ユーザーを見つけ、sessions.timestampが制限を超えている場合はセッションを削除する必要があることを意味します。 system.installによると、その列にはThe Unix timestamp when this session last requested a page.が含まれています

セッションテーブルの制限はデータベースサーバーのハードウェアによって異なりますが、かなり大規模なサイトでの私の経験では、何百万ものセッションレコードを保持できるため、パフォーマンスに大きな問題はありません。とはいえ、ユーザーインタラクションはパワーカーブに従うこともわかりました。コミットしてエンゲージしたユーザーの90％は、1日以内にそうしました。 95％は最初の1週間以内で、3か月に出かけると98％に達しました。丸め誤差に相当する量を超えてCookieデータを保存することは、通常、あまり役に立ちません。

SQL削除を直接実行しようとすると、うまく拡張できないことがわかりました。代わりに、削除するレコードを見つけて、条件WHERE sid = :sidで個々の削除クエリを実行するループを作成したため、主キーを使用していました。これは、最小限の影響で最大のパフォーマンスを発揮しました。読み取りレプリカデータベースに対して選択を実行して、パフォーマンスへの影響をさらに減らすこともできます。私のシナリオでは、過去1時間アクティブでなかった1クラスのユーザーがログアウトされ、ジョブは1時間ごとに実行されました。 3か月後に削除された他のクラスのユーザーは、より多くの操作を実行し、サーバーリソースにより大きな影響を与えたため、夜間に実行されるジョブで削除されます。

セッションデータを2年間保存する必要がある場合は問題ありません。ただし、セッションではなくCookieにデータを格納できるかどうかを検討する場合があります。これにより、セッションテーブルは軽量なままで、Cookie内でユーザーの追跡を行うことができます。たとえば、ユーザーをサイトに誘導したチャネルを追跡することが目的の場合、$_SESSIONではなく、そのチャネル情報をCookieに保存するだけで済みます。セッションの生成/保持を回避できれば、スケーラビリティの問題はなくなります。

多くのスパイダーとボットは大量のトラフィックを生成し、セッションに関連して動作が悪いことに注意してください。Cookieを破棄し、アプリがそれを行うと、すべてのページリクエストに対して新しいセッションを効果的に生成します。ボットブロッキング/キャッシングネットワークを前面に配置するか（Cloudflareなど）、定期的にセッションテーブルを分析し、IPアドレスなどに基づいてこれらのボットからセッションを削除することを計画できます。

この目的でmemcacheを使用することはお勧めしませんが、代わりにSQLデータベース（おそらく専用のデータベースインスタンス）またはRedisを使用します。 Memcacheは一時データストアとして最適化されています。意図的に、sqlまたはredisが提供する永続データストアが必要です。

1
greggles

アプローチ1、

  1. 必要に応じて、セッションとCookieの有効期間を延長します。
  2. セッションをファイルベースのセッションからMemcachedに移動します。これはphp.iniで行うことができます。

つまり、基本的にすべてのユーザーに最も長いセッションを提供します。そして、多分あなたはあなたがより短いスパンを必要とする役割のユーザーのセッションを無効にするためのルールまたはcronjobを書くことができます。

2つのアプローチ、私はより良いと思いますhttps://www.drupal.org/project/persistent_login

参照： http://www.jaspan.com/improved_persistent_login_cookie_best_practice

0
esafwan