0

クライアント側の検証に ASP.Net 検証コントロールと JavaScript を使用することの違いを説明してもらえますか? 私の仕事は、開発者によって作成されたコードを分析することです/私はいくつかの記事を読みましたが、リアルタイムでは、開発者は検証コントロールを使用するよりも JavaScript を好みます。したがって、検証コントロールの代わりに JavaScript を使用する必要性を理解したいと思います。

4

2 に答える 2

3

違いは、ASP.NET クライアント コントロールがサーバー上で検証を実行することです。これは常に実行する必要があります。クライアント側の JavaScript 検証はオプションです。UI の応答性が向上し、サーバーへのラウンドトリップが少なくなりますが、ユーザーはブラウザーで JavaScript をオフにするだけで済むため、セキュリティ レベルは提供されません。ASP.NET コントロールには、サーバー側だけでなく、クライアント側の検証も生成する可能性があります。

于 2013-10-23T06:28:18.640 に答える
2

クライアント側

平均的なユーザーにより良いフィードバックを提供できるため、最初にクライアント側で入力を検証する必要があります。たとえば、無効な電子メール アドレスを入力して次のフィールドに移動した場合、すぐにエラー メッセージを表示できます。そうすれば、ユーザーはフォームを送信する前にすべてのフィールドを修正できます。

サーバーでのみ検証する場合、フォームを送信し、エラー メッセージを取得して、問題を突き止めようとする必要があります。

(この問題は、サーバーが各フィールドに入力された内容を記憶して入力し直す「粘着性のある」フォームを作成することで緩和できますが、クライアント側の検証は依然として高速です。)

ASP.Net コントロールの検証 (サーバー側)

JavaScript を簡単にバイパスして危険な入力をサーバーに送信できる悪意のあるユーザーから保護できるため、サーバー側で検証する必要があります。

UI を信頼することは非常に危険です。UI を悪用できるだけでなく、UI をまったく使用していないか、ブラウザさえも使用していない可能性があります。ユーザーが手動で URL を編集したり、独自の Javascript を実行したり、別のツールで HTTP 要求を微調整したりした場合はどうなるでしょうか? たとえば、curl からカスタム HTTP リクエストを送信するとどうなるでしょうか?

それを許可しないことは、セキュリティの観点からナイーブであるだけでなく、非標準でもあります。クライアントは、任意の方法で HTTP を送信できるようにする必要があり、正しく応答する必要があります。これには検証が含まれます。

サーバー側の検証も互換性にとって重要です。すべてのユーザーが JavaScript を有効にしているわけではありません。

于 2013-10-23T06:29:43.590 に答える