9

私はこれについてどこにも多くを見つけることができませんでした。サンプル アプリケーションのほとんどは、セキュリティなどについて触れていません。ユーザーは REST ベースの API 呼び出しを使用して認証されると想定します。認証を処理するためにアプリケーションをどのように構成する必要があるか [また、承認]。サンプル アプリケーションへのポインターは素晴らしいでしょう。通常のアプリケーションだけでなく、単一ページのアプリケーションの観点からビューを追加してください。[各ビューがそれを処理する必要があると思います]

4

3 に答える 3

8

ほとんどのサンプルがセキュリティにまったく対処していないことは間違いありません。その結果、私はあなたを指し示すことができる素晴らしいサンプルを持っていません. 私たちが独自のものをどのように構築したかをお伝えすることしかできません。

  1. あなたが提案したように、ユーザーを認証するために API 呼び出しを行います。私たちの場合、ユーザーが最初のページにアクセスするとすぐに (ログイン前であっても)、Java サーバーによってセッション ID が作成され、Cookie クライアント側に保存されました。その Cookie は、サーバーへのすべての HTTPS 要求 (データを取得したりコマンドを実行するための AJAX 呼び出しであっても) で移動するため、ユーザーが認証されると、特定のアカウント サーバー側に関連付けられます。

  2. サーバーへのトランスポートが HTTPS であり、Cookie がオープンなインターネットを経由しないと仮定すると、誰もその値を盗聴して、ログインしているユーザーになりすますことはできません。

  3. 私たちの場合、サーバーは Java ベースであり、サーブレット フィルターは、パブリックにアクセスできないすべての API 関数 (つまり、ログインが必要なもの) の前にあります。セッションをチェックし、リクエストをサービスに渡す前にログインしているユーザーを表していることを確認します。これにより、サービス コードの認証チェックがクリーンに保たれます。ただし、承認コードとパラメーターの検証は現在、サービス レイヤーにあります。

  4. API への AJAX 呼び出しは、さまざまな理由 (セッションの有効期限が切れた、サーバーを再起動する必要があり、ユーザーのセッションを忘れた、管理者がユーザーを強制的にログアウトした、等。）。私たちの意見では、サーバーが何かを返す (つまり、空の応答ではない) ことが重要であり、ログイン ページへのリダイレクトのようなものであってはなりません (これは AJAX 要求には役に立ちません)。したがって、常にJSend プロトコルを返しますすべての関数からの応答を受信し、ユーザーがログインしていない場合、サーブレット フィルターは特定のコードを含む標準の JSend "エラー" 応答を返します。これにより、ユーザーがログインしていないことをクライアント側のコード (カスタム Sync に入れることができます) に通知し、ログインを要求することができました。ログイン後に関数を自動的に再試行することもできますが、それは私たちが得たよりも洗練されています.

  5. ユーザーがログインしていない、またはセキュリティ違反が発生したことを Sync に通知させることで、ビューに特別なものを追加する必要がなくなります。彼らは自分が適切だと思う要求をするだけで、それが成功するか失敗するかのどちらかです。新たなログインが必要な場合は、下位レベルでトリガーされます。

  6. サーバーが特定のセッションにログインしていないことを示すか、セッション レコードを破棄する限り、ログアウトしても実際にはローカル Cookie を強制終了する必要はありません。

クライアントはセキュリティについて知っておくべきではないという Derick の声明には、私は多少同意できません。ログインを要求するタイミング、ログアウトを実行するタイミングをサーバーに伝える方法を知る必要があると思います。驚きの原則を避けるために、クライアント側で追加のチェックを行うことを常にお勧めします。たとえば、クライアントが管理機能を使用できない場合は、それらを呼び出してエラーが返されるようにするよりも、管理機能を表示しないようにすることをお勧めします。

最終的に、サーバーはリクエストごとにユーザーのアクセス許可を再度確認する必要があります (クライアント側のセキュリティを回避するのは非常に簡単であるため)。私にとってのUI。

于 2012-06-06T20:27:02.537 に答える
5

数か月前に、RESTベースのAPIを使用するシングルページアプリを実行して同じ問題が発生しました。答えを探して思いついたのは、HTTPの既存の401および403エラーを使用することでした。APIにこれらのエラーを返してもらいました。次に、拡張エラー処理モデルを使用してこれらのエラーを処理し、ルーターのナビゲート機能を介してログインにルーティングすることで、例外をキャッチしました。

var ErrorHandlerModel = Backbone.Model.extend({

    initialize: function(attributes, options) {
        options || (options = {});
        this.on("error", this.errorHandler);
        this.init && this.init(attributes, options);
    },

    errorHandler: function(model, error) {
        if (error.status == 401 || error.status == 403) {
          app.history.navigate('login', true);
        }
    }

});

後から考えると、代わりにグローバルjqueryajaxError関数を使用したほうがよいと思います。上記のスニペットは、数か月前にここに投稿された同様の質問に基づいています。

また、バックボーンのデフォルトのフェッチ動作をオーバーライドして、APIのjson応答に含まれる応答変数をキャッチするためにoginでエラーをトリガーできるようにする必要がありました。

var Login = Backbone.Model.extend({  

    urlRoot: '/login',

    parse: function(resp,xhr) {
        if (resp.response == 'success') {
            app.history.navigate('dashboard', true);
        }
        else {
            this.trigger('loginError');     
        }
    return false;
    }
});
于 2012-06-06T21:03:28.853 に答える
1

ムーさんの意見に賛成です。認証に関して話すことはほとんどありません。

サーバーにポストバックする標準の HTML アプリで認証をどのように処理しますか? それがそうあるべきだから、そのようにしてください。

承認については、もう少し話がありますが、それほど多くはありません。基本的に、ユーザーが見ることを許可されているものだけをユーザーに送信します。絶対に必要な場合を除き、ブラウザーで承認または認証コードを実行しません。そして、私の経験では絶対に必要というわけではありません。

ブラウザーの JavaScript は安全ではないため、ブラウザーでの認証と承認に依存することは行わないでください。

私はこれについていくつかの小さな記事を書きました: http://lostechies.com/derickbailey/2012/01/26/modularity-and-security-in-composite-javascript-apps/

于 2012-06-06T20:11:35.220 に答える