Web アプリケーションで使用されている非表示のフィールドがたくさんあるのを、私はいつも見てきました。私は、多くの隠しフィールドを使用するように記述されたコードと、それらとの間でやり取りされる可視フィールドからのデータ値を使用して作業しました。隠しフィールドが使用される理由を理解できませんが。ほとんどの場合、隠しフィールドを使用せずに同じ問題を解決する方法を考えることができます。隠しフィールドは設計にどのように役立ちますか?
隠しフィールドが提供する利点を正確に教えてくれる人はいますか? 非表示フィールドが使用される理由
隠しフィールドは最も簡単な方法です。そのため、隠しフィールドがかなり使用されています。
代替案:
主な懸念事項:
主な利点:
オブジェクトを編集するとします。ID を隠しフィールドに入れると便利です。もちろん、その値に依存してはinsertいけません (つまり、ユーザーが/に対して適切な権限を持っていることを確認してupdateください)。
それでも、これは非常に便利なソリューションです。ID を表示可能なフィールド (読み取り専用のテキスト ボックスなど) に表示することは可能ですが、ユーザーを苛立たせます。
ID をセッション / Cookie に保存することは、同時に複数の編集ウィンドウを開くことを禁止し、有効期間の制限を課すため、禁止されています (セッション タイムアウトは編集操作の破損につながり、非常に煩わしい)。
URL を使用することは可能ですが、データを変更するときに POST を使用するなど、設計規則に違反します。また、ユーザーに表示されるため、より醜い URL が作成されます。
私が見たり使用したりする最も典型的な用途は、ある時点でサーバーに送り返す必要がある以外の理由で、実際にはページに存在する必要のない ID やその他のものです。
-編集、詳細を含める必要がありました-
たとえば、更新したいオブジェクトがあるとします。UI は値のコレクションを送り返し、その時点でサーバーは「これは顧客オブジェクトです」と認識している場合と認識していない場合があるため、サーバーにリクエストを送信し、 「ねえ、ID 7 をくれ」と言うと、システムが認識している顧客オブジェクトができました。更新が適用され、検証され、UI が完成した結果を取得します。
良い言い訳/議論はlinqを使用していると思います。最初に DB からオブジェクトを取得せずに、linq でオブジェクトを更新してみてください。完全なオブジェクトを取得するまで、それが追跡できるものであるという本当の考えはありません。
理由の 1 つは、クライアント コード (javascript) とサーバー側の間でデータを渡す便利な方法です。
便利なシナリオがたくさんあります。
1 つは、ユーザーが入力してはならないデータをページに「保存」することです。たとえば、ページを生成するときにユーザー ID を保存すると、この値がフォームと共にサーバーに自動送信されます。
もう 1 つのシナリオはセキュリティです。ページに隠しトークンを追加し、サーバー上でその存在を確認します。これは、フォームがブラウザー経由で送信されたのか、サイトの URL に投稿されたばかりのボットによって送信されたのかを識別するのに役立ちます。
URL から (クエリ文字列のように) 除外されるため、クリーンな状態が維持されます。また、必ずしもそこにある必要のないものをセッションから除外します。
それ以外に、あまり多くの利点を考えることはできません。
これらは通常、インタラクションが進行するにつれて状態を保存するために使用されます。代わりに Cookie を使用することもできますが、Cookie を無効にする人もいます。単一の非表示フィールドを使用してサーバー側の状態を指すこともできますが、セッション固定の問題があります。
フォームで隠しフィールドを使用している場合、新しいコントロールを含めることでフォームの負担が増えています。
隠しフィールドを取る必要がない場合は、セキュリティポイントの観点から適切ではないため、取るべきではありません。隠しフィールドを使用することは、適切なプログラミングには当てはまりません。アプリケーションのパフォーマンスにも影響するためです。