私は次のような小さなジレンマを持っています。私はバックボーンアプリを持っています。ほとんどの場合、ルートベースです。つまり、nameoftheapp/photos/1/editにすると、特定の写真の編集ページに移動します。問題は、私のビューロジックがクライアント側でほぼ100％（私はストレージと検証のために薄いサービスベースのサーバーを使用しています）、そのページに到達する権限のないユーザーの種類の問題を避けるにはどうしてですか？もちろん、ユーザーが承認されていれば、ルーターにチェックをさせることもできますが、これはすでに検証の面で重複しています。もちろん、私は検証なしでサーバー側を離れることはできません。なぜなら、APIはあらゆる種類のアクセスにさらされるからです。Backbone.jsの経路変更の検証
私は今のところ他の方法はありません。誰かが賢明なアイデアを思いついていない限り、私はクライアントとサーバー側の両方の検証を複製する必要があると思います。
基本的なルールは、 "クライアントを信頼しないでください"でなければなりません。彼らに許されていないことを決してクライアントに届けないでください。
したがって、ユーザーがnameoftheapp/photos/1/editに行くと、おそらくサーバーからイメージを取得しようとします。
サーバーはHTTP 401応答（無許可）で応答する必要があります。
あなたのビューにはこのためのエラーハンドラがあり、それが許可されていないことをユーザーに通知する必要があります。どのような方法であれ、編集ビューのエラーメッセージ、または "history.back（）前のページに戻ります。
したがって、検証ロジックを重複させる必要はありません。サーバーからの検証応答に有意義に応答できるようにするには、単にビューが必要です。
「効率的ではない - より多くのAPI呼び出しを作成する」と言われるかもしれませんが、許可されていない呼び出しは、通常の方法でアプリを使用するユーザーの通常の発生ではありません。とにかくネットワークタブを見てすべてのAPI呼び出しを見つけ出し、必要なツールを使って直接APIをヒットすることができます。したがって、クライアントで検証が行われていれば、実際にAPIトラフィックはなくなります。
以前は同じ問題が発生しました。サーバー側の検証を使用することをお勧めします。私の提案... Backboneの依存関係であるUnderscoreのようなテンプレートエンジンを使用し、テンプレートを設計し、認証されたユーザーまたは権限を持つユーザーのみがアクセスできるルートについては、サーバーにいくつかのCSRFトークン、またはsession_id、またはその両方（または選択した他のサーバー側の検証方法）に基づいてデータが欠落している（通常は小さなjsonデータ）場合、テンプレートをレンダリングします。そうでない場合は、同じテンプレート...ロジックは簡単です...