JavaScriptが機能することを絶対に必要とするフォームがあり、検証はクライアント側で行われます。検証はサーバー側でも実行されますが、サーバー側の検証が失敗したときにエラーを表示させるのは非常に手間がかかります。
ユーザーがJavaScriptを持っていない可能性はないので、HTTPエラーで失敗しても大丈夫ですか？サーバー側の検証に失敗する唯一の方法は、悪意のあるユーザーであるか、JavaScriptを使用できない場合でした。その場合、フォームは使用されません。
ありがとう
4 に答える
2
特定のクラスのエラーを除いて、これは問題ないと思います。
一部の検証エラーは悪意の結果ではありませんが、フォームが実際に処理されるとき以外はチェックおよび検出できません。これは、予約する必要があるが予約できないリソースが不足している（「このユーザー名はすでに使用されています」）か、サーバー側の回復可能なエラー（「アップストリームのクレジットカードプロセッサが応答していません。もう一度やり直してください」）が原因である可能性があります。後で"）。これらの種類のエラーについては、絶対に何らかのエラーメッセージをユーザーに通知する必要があります。この種のエラーを送り返すことができない設計を想像するのは難しいです。少なくとも、これを行うことができます：
- HTTPエラー応答を送信します（エラーの性質に応じて4xxまたは5xx）
- 応答の本文で、JavaScriptが簡単に理解できるデータ構造にエラーメッセージをパッケージ化します。（JSONまたはXML、あるいはテキスト/プレーン！mimeタイプを設定することを忘れないでください。）
- javascriptリクエストのエラーハンドラーに、フォームの表示されている場所（たとえば、上部または送信ボタンの近く）にエラーのテキストを挿入してもらいます。
ただし、最も重要なことは、サーバー側の検証を行い、クライアントを信頼しないことです。あなたはすでにこれを行っているので、さらに何かをしたいのであれば、それは磨きをかけ、可能な限り最高のユーザーエクスペリエンスを実現することです。時にはそれは不釣り合いな量の努力を必要とし、それは大丈夫です。
于 2011-12-19T01:47:02.790 に答える
0
個人的には大丈夫だと思います。
特に、サイトを使用する前のステップもJavascriptなしではまったく機能しないため、ユーザーがJavascriptなしで問題のページに進むことができなかった場合、Javascriptなしでサイトを機能させるための莫大な費用が無駄になります。たとえば、.Net Webフォームでは、ログインにはJavascriptが必要であるため、サイトのセキュリティで保護された領域内のすべてのページで、Javascriptが利用可能であると想定できます。
でも、他の人がどう思うか気になります。
于 2011-12-19T01:31:34.560 に答える
0
httpリクエストが失敗する唯一の予想されるユースケースが、誰かがブラウザをバイパスした場合である場合、httpリクエストを失敗するだけで完全に問題ないように見えます。予想されるユーザーシナリオに影響を与えることはありませんが、サーバー側の検証によってサーバー側の整合性を保護しています。それ以上の仕事をする意味はありません。私には問題ないようです。
サーバーからエラーUIを表示するためにさらに作業を行う価値があるのは、不良データがサーバーに到達する実際の正当なユーザーシナリオがある場合です。しかし、正当なシナリオがそこに到達する可能性は低いか不可能であると考えるので、その余分な作業を行う理由はありません。
于 2011-12-19T01:46:23.757 に答える
0
クライアント側の検証とサーバー側の検証が同等であることが確実である限り、問題ありません。その点で、クライアント側の検証コードとサーバー側の検証コードを同期させるのは面倒だと思います（特に、それらが異なる言語で書かれている場合、node.jsまたはGWtを使用していない場合は常にそうです） ）。誰かがそれが素晴らしいだろうという解決策を持っているなら。
ただし、サーバー側でのみ実行できる特定の検証（データベースの一意性の制約など）がある場合は、クライアント側のアクションが失敗したことをユーザーに示すことが重要です。ただし、それはアプリケーション自体に依存します。
于 2011-12-19T01:49:55.917 に答える