0

などのドメイン制約を使用してユーザー入力を検証し、エラー メッセージを作成するなどの入力email(unique:true)に依存することをお勧めします。それとも、ドメインへの永続化を試みる前に、Web サービスでクライアント側の検証またはチェックを実行する方がよい方法ですか?message.propertiesclassName.email.unique=Email address already in use

4

2 に答える 2

2

クライアント側とサーバー側の両方を使用するのが一般的です。

クライアント側の検証は、ユーザーの利便性を高め、帯域幅を削減したり、ワークフローを改善したりできますが、100% 信頼できるわけではありません。

クライアント側のバリデーションは美的な魅力があり、ポスト操作の前にユーザーに間違いを警告することができます。見栄えは良くなりますが、ユーザーにとっては良いことですが、不正な入力を止めることはできません。ユーザーはページを操作し、適切な処理を行う前に複数の不適切な入力を送信する帯域幅を減らすことができれば幸いです。

ページのソースをローカルで編集して、最も適切な形式の検証でさえも無効またはバイパスし、それを完全に抑制することができます。そのため、クライアント側でできることは、決心したユーザーがあなたのページを台無しにするのを止めることはできません。システム。

これは、適切なサーバー側の検証も必要であることを意味します。インジェクションやその他の種類の無意味なユーザーが意図的または偶然にやってのける可能性があることから身を守ることをお勧めします。特に、Web 上にいる場合はそうです。両方の検証を行うことで障害点を減らすことは、どちらも価値があるため、推奨される方法です。

于 2013-09-19T09:18:23.813 に答える
0

リクエスト ペイロードを受け入れるときは、コントローラ アクションで CommandObjects を使用することを検討する必要があります。

http://grails.org/doc/latest/guide/single.html#commandObjects

コマンド オブジェクトを使用すると、リクエスト ペイロードに検証ルール/制約を設定できます。ロジックにヒットさせることなく、Web からのペイロード リクエストに固有の新しい制約を適用できるため、これで問題ありません。優れた機能は、ドメインの制約を継承できることです。

@grails.validation.Validateable
class LoginCommand {
    String username
    String password
    static constraints = {
       username(blank: false, minSize: 6)
       password(blank: false, minSize: 6)
    }
}
于 2013-09-19T15:47:03.723 に答える