2011-01-31 6 views
2

これは初心者向けの質問です...PHP - セッションにはどのようなデータを含める必要がありますか?

ウェブサイトでは、どのようなタイプのデータをセッションに含めるべきか、含まないべきですか?私は安全のために必要な情報を含めてはならないことを理解しています。私はベストプラクティスのプログラミングにもっと興味があります。例えば、依存性注入としてページからページに送られるであろういくつかのデータをセッションに含めることが可能である。グローバル変数の作成には対応していませんか?

一般的に言えば、どのような種類のデータがセッションテーブル内にあるのでしょうか?

おかげで、

JDelage

+0

「ベストプラクティス」の回答を得るには質問が広すぎるとは思われませんか? –

答えて

1

あなたのセッションはライトワンスとして扱う必要があります。しかし、かなり揮発性のあるもの、例えば、すべてのセッションが突然消えた場合、基礎となるアプリケーションデータの状態は一貫している(または回復可能である)必要があります。

これにはいくつかの例外があります(通常、買い物カゴはセッションに保存されますが、チェックアウト前に在庫を調整することができます)。ここでは、アイテムの追加/編集/複数回の変更が可能です。つまり、実際にはライトワンスではありませんが、データベースの回復可能性を維持している在庫アイテムを事前に予約することによって実現します。しかし、これは株式調整を逆転する必要があることを意味します。セッションが完了しない場合には、が期限切れになります。

個々のページめくりに関するデータの情報を保存しようとすると、ユーザーが早送り/巻き戻しボタンのクリックを開始するか、新しいウィンドウを開くときにすぐに問題に陥ります。

7

要求間で必要な状態情報を維持するために必要な最低限の情報。

+0

私は通常、UID、CSRFのハッシュ、Captchaの値などに配置します。+1 – RobertPitt

+0

@RobertPitt - CSRFとは何ですか? Thx – JDelage

+1

@JDelage Type CSRFを好きな検索エンジンに追加 –

1

一般に、好きなものをセッションに入れることができます。あなたのページを(技術的な)エラーなしで動かすために存在しなければならないセッションに情報を入れるのは悪い習慣です。

セッションのデータ量をできるだけ少なくすることをお勧めします。

1

あなたはセッションに保存することができますので、変更されない情報に対して別のデータベースクエリを作成する必要はありません。あなたのサイトのユーザー名、住所、電話番号、アカウントの残高、セキュリティ権限などのようなものです。

1

(これはおそらくあなたが探している以上のものですが、投稿されました)

あなたはベストプラクティスについて言及しているので、セッション状態のアイデアを少しでも引き出す​​ために使用できるいくつかのプロジェクト/技術を調べることができます。複数のサーバー間で水平方向にWebアプリケーションをスケーリングする一般的な落とし穴の1つは、それらの間のセッション状態を維持することです。 (ユーザーAは、ユーザーのセッションを格納しているサーバーAにログインしますが、次の要求でサーバーBはユーザーAのセッションについて知らないサーバーBをヒットします)

私はいつも自分自身同僚だけでは、たとえそのデータが事実上非常に過渡的であっても、セッション自体は実際にはデータを保存するのに最適な場所ではないということです。 Webサーバーは、要求/応答システムであり、データストアではありません。それは前者に高度に調整されていますが、後者にはそれほど大きくないとは限りません。

このように、アプリケーションのセッションデータ(またはWebのRESTfulステートレスな性質の中で実際に最低限の状態に保たれるステートフルなデータ)をWebサーバーや別のシステムに外部化する方法があります。 Memcachedはこのための非常に一般的なツールです。また、SQLやMySQLのようなデータベースにセッションを保存するドロップインセッションの置き換え(またはさまざまなフレームワーク/環境用の設定可能なセッションオプション)もあります。

私は最近、NoSQLデータベースでセッションデータ(災害時に失われても問題ない任意の一時的なデータ)を保存することを考えています。 CouchDBMongoDBは私の現在の選択肢ですが、他にもオプションがありません。 CouchDBは優れた水平スケーリング機能を備えており、MongoDBは完全にメモリ内で実行されると非常に高速です。

少なくとも私の場合、このようなものの大きな利点の1つは、展開が簡単に非イベントになることです。任意のサーバ上のウェブサービスを再開することができ、その中のアプリケーションをステートフルデータを失うことなく再初期化することができる。データがディスクに永続化されている(つまり、メモリ内で完全には実行されていない)場合は、サーバーを失うことなく再起動することもできます。サーバー/サービスはファーム内外にドロップすることができ、ユーザーはその違いを知ることができません。

さらに、このデータを外部化することで、潜在的に有用な方法でデータを分析することができます。他のWebアプリケーションや完全にオフラインのツールなどを介してそれと照らし合わせて、それと照らし合わせることができます。プロジェクトが複雑になるにつれて、実際にオプションが開きます。

(これは本当にあなたの質問に答えるつもりではなく、役に立つと思う情報を追加することです。私の同僚と私は遅れています。あなたの質問は良いそれに言及する場所)。

+1

Re:セッションストレージをNoSQLに「全メモリで実行すると」、セッションストレージパスをRAMディスクに設定してみませんか?あなただけのためにそれを使用している場合は、中央にデータベースサーバー全体をスローしないでください。 –

関連する問題