これを実行するかどうかについてはまだ議論中ですが、ユーザーがアプリのHTMLフォームにハイパーリンクを入力できないようにすることを検討しています。これは、アプリがユーザー生成コンテンツに基づいているため、スパムリンクがアプリの他の用途に表示されないようにするためです。
これはRailsアプリなので、ユーザーがフォームを送信した後、モデルに対してバックエンド検証を行うことができます。
しかし、送信が行われる前にjQuery/JavaScriptでチェックを実行することが望ましいのではないかと思いました。このようにして、バックエンド処理なしでユーザーにすぐに通知できます。
ここではどちらが望ましいですか？クライアント側またはサーバー側の検証ですか？
データがサーバーに到着したときにのみ、データを制御できます。JavaScriptを使用してスパムを取り除こうとすると、スパマーはJavaScriptをオフにするだけです。
サーバー側のソリューションを構築します。
それができたら、作業クライアント側を複製して、ユーザーにとってより良いものにすることを検討してください。
両方を使う。
クライアント側の検証は、クライアントでJavaScriptがオンになっている場合に、サーバーへのストレスを軽減します。
サーバー側は、ユーザーがJavaScriptをオフにしている場合に備えて、最後の防御線です。
あなたは言う ：
そのため、ユーザーがフォームを送信した後、モデルに対してバックエンドの検証を行うことができます。
いいえ ！バックエンドで検証を行う必要があります！
Javascriptを無効にしたり、フォームの投稿を偽造したりできます。したがって、バックエンド/サーバーで必要な検証/フィルタリング/セキュリティ対策を常に開発する必要があります。
そうして初めて、最終的にJSを追加できるようになるため、アプリケーションはよりユーザーフレンドリーになります。
両方............
両方を使用し、クライアントでjQuery検証プラグインを使用し、バックエンドで適切な方法を使用する必要があります（RORはわかりません）。
ajaxy検証ソリューションは、クライアントが情報を入力している間にサーバー側の検証を実行し、それに応じてフィードバックを提供したり、送信を防止したりできます。
お役に立てば幸いです。
スパマーは、フォームを分析し、フォームデータと投稿を独自に構築するある種のスクリプトを使用することが多いため、クライアントスクリプトは、ほとんどのスパムに対してまったく役に立ちません。
JavaScriptの検証は、悪意のないユーザーの手を握る方法として最適です。「入力したパスワードが一致しません」、「無効なメールアドレスのようです。再確認してください」など。
JavaScriptの欠点は、JavaScriptが実行されたこと、または意図したとおりに実行されたことを確認する方法がないことです。悪意のあるユーザー、グリッチなブラウザプラグインを使用しているユーザー、熱心なファイアウォール/コンテンツブロッカーを使用しているユーザー、JavaScriptを使用していないスパムボット、NoScriptを有効にしているユーザー、またはその他のさまざまな状況では、検証がトリガーされない可能性があります。
そのため、検証が必要な場合、サーバーは常にデータを検証する必要があります。JavaScriptは最初の防衛線になる可能性がありますが、最後の防衛線になることはありません。