state - 状態を維持する方法の比較

Question

Web 開発で使用するユーザー状態を維持するには、さまざまな方法があります。

これらは私が今考えることができるものです：

クエリ文字列
クッキー
フォームメソッド (Get および Post)
Viewstate (私が推測する ASP.NET のみ)
セッション (InProc Web サーバー)
セッション（専用Webサーバー）
セッション (データベース)
Local Persistence (Google Gears) (thanks Steve Moyer) など

Cookie は安全ではなく、QueryString には長さの制限があり、見栄えが悪いなど、各方法には独自の長所と短所があることを私は知っています。;)

しかし、Web アプリケーションを設計するとき、どのアプリケーションにどのメソッドを使用するか、またはどのメソッドを避けるべきかについて、私はいつも混乱します。

私が知りたいのは、あなたが一般的にどの方法を使用して推奨するか、またはより興味深いことに、特定のシナリオでこれらの方法のどれを避けたいのか、そしてその理由は何ですか?

score 12 · Accepted Answer

これは答えるのが非常に複雑な質問ですが、状態の実装を検討するときに私が考えるいくつかの簡単なことを持っています。

クエリ文字列の状態は、最も基本的なタスクにのみ役立ちます。たとえば、ウィザード内でユーザーの位置を維持したり、特定のタスクの完了後にユーザーをリダイレクトするパスを提供したりします（ログインなど）。そうしないと、クエリ文字列の状態はひどく安全でなく、実装が難しくなります。それを正しく行うには、クライアントをそのクライアントのサーバーの維持状態に関連付けるキーを含めることで、サーバー側のステートマシンに関連付ける必要があります。
Cookieの状態はほぼ同じです。つまり、クエリ文字列の状態よりも優れています。ただし、Cookie内のデータがクライアントをサーバー側のステートマシンに結び付けるためのキーでない限り、クライアント側では完全に維持されます。
フォームメソッドの状態も同様です。特定のフォームをバックエンドのデータの一部に関連付けるフィールドを非表示にする場合に便利です（たとえば、「このユーザーはレコード＃512を編集しているため、フォームには値を含む非表示の入力が含まれます。 512 "）。これは他の多くの場合には役に立ちません。また、クエリ文字列とCookieの状態の背後にある同じアイデアの単なる別の実装です。
セッション状態（あなたが説明する方法のいずれか）はすべて素晴らしいです。なぜなら、それらは無限に拡張可能であり、選択したプログラミング言語が処理できるものなら何でも処理できるからです。最初の注意点は、クライアントをサーバーに保存されている状態に結び付けるために、クライアントの手にキーが必要であるということです。これは、ほとんどのWebフレームワークがCookieベースまたはクエリ文字列ベースのキーをクライアントに提供する場所です。（ほとんどすべての最新のものはCookieを使用しますが、Cookieが有効になっていない場合はクエリ文字列にフォールバックします。）2番目の注意点は、状態の保存方法にいくつかを入れる必要があるということです...データベース？あなたのウェブフレームワークはあなたのためにそれを完全に処理しますか？繰り返しになりますが、ほとんどの最新のWebフレームワークはこれから作業を取り除きます。私が自分のステートマシンを実装するためには、非常に必要です。正当な理由...そうでなければ、成熟したフレームワークのいずれかで時間の経過とともにハッシュ化されたセキュリティホールと機能の破損を作成する可能性があります。

ですから、最も些細な理由以外の理由でセッションベースの状態を使用したくないとは本当に想像できないと思います。

score 3 · Accepted Answer

セキュリティも問題です。クエリ文字列またはフォームフィールドの値は、ユーザーが簡単に変更できます。ユーザー認証は、暗号化されたCookieまたは不正開封防止Cookieのいずれか、またはサーバー側のセッションに保存する必要があります。ユーザーがサイトのサインアップなどのプロセスを完了するときにフォームに渡された値を追跡することは、おそらく非表示のフォームフィールドに保持することができます。

ただし、クエリ文字列の良い点（場合によっては危険な点）は、リンクをクリックした人なら誰でも状態を取得できることです。上記のように、これは、ユーザーが持つべきではない認証をユーザーに与える場合、危険です。ただし、サイトで見つけたものを友達に見せてくれるのはいいことです。

score 2 · Accepted Answer

Web 2.0の使用が増えるにつれ、リストにない2つの重要な方法があると思います。

8 AJAXアプリケーション-ページはリロードされず、ページ間のナビゲーションがないため、状態は問題になりません（ただし、ユーザーデータの永続化には非同期XML呼び出しを使用する必要があります）。

9ローカル永続性-ブラウザベースのアプリケーションは、Google Gearsなどのライブラリを使用して、ユーザーデータと状態をローカルハードドライブに永続化できます。

どちらが最適かというと、それらはすべてその場所を持っていると思いますが、クエリ文字列メソッドは検索エンジンにとって問題があります。

score 1 · Accepted Answer

データを取得する必要がある場合に、ある種のデータベースストアにリンクされた署名付きCookie 。バックエンドが接続されている場合は、クライアント側にデータを保存する理由はありません。これが公開されているWebサイトである場合は、問題を探しているだけです。

score 1 · Accepted Answer

個人的には、Web 開発はほとんどすべて PHP で行っているため、PHP のセッションハンドラを使用しています。

私の経験では、セッションは最も柔軟です。通常、セッションは db アクセスよりも高速であり、ブラウザーが閉じると (デフォルトで) 生成された Cookie は消滅します。

score 1 · Accepted Answer

クライアント側に保存する状態 (クエリ文字列、フォームフィールド、Cookie) に注意してください。セキュリティに関連するものはすべて、クライアント側に保存しないでください。ただし、セッション ID がかなり不明瞭で推測しにくい場合を除きます。「authenticated=true」のような設定があり、それらを Cookie やクエリ文字列、または非表示のフォームフィールドに保存する Web サイトが多すぎます。ユーザーがそのようなものをバイパスするのは簡単です。クライアントからの入力はすべて改ざんされている可能性があり、信頼すべきではないことに注意してください。

score 1 · Accepted Answer

webhost4life のような安くて陽気なホストで Web サイトをホストする予定がある場合は、InProc を避けてください。彼らのシステムはオーバーサブスクライブされているため、アプリケーションを非常に頻繁にリサイクルし、セッションが失われるという難しい方法を学びました。とてもうるさい。

彼らの提案は、セッションをシリアライズ/デシリアライズする必要があることを除いて、StateServer を使用することです。私はオブジェクトが大好きで、私の Web アプリはそれらでいっぱいです。StateServer に切り替える際のパフォーマンスが気になります。本当に必要なものだけをセッションに入れるようにリファクタリングする必要があります。

始める前に知りたかった…

乾杯、ロブ。

score 0 · Accepted Answer

何を使用し、何を回避するかではなく、いつどちらを使用するかが問題になります。それぞれに、最高の場合は特定の状況があり、最悪の場合は異なる状況があります。

決定要因は、通常、データの存続期間です。セッション状態は、フォームフィールドなどよりも長持ちします。

state - 状態を維持する方法の比較

8 に答える 8

Related

Reference