2

私は完全に分離された HTML5 フロントエンドを持つという考えで遊んでいますが、それでも Web アプリのユーザー認証を行います。これは可能ですか、それともブラウザーのセキュリティに重大な問題が発生する可能性がありますか?

example.com のような CDN を介してすべての静的コンテンツを配信し、api.example.com のような別のサブドメインを介して動的データ (およびユーザー認証) をフェッチするという考え方です。これにより、サイトの読み込み時間が短縮され、開発者が新しい機能を開発およびテストするためにバックエンドをセットアップすることを心配する必要がないように、フロントエンドのものを完全に別のリポジトリに保持できます。

おそらくbackbone.js、angular.js、ember.js、knockout.jsなどのJSフレームワークでこれはすでに可能ですか?

4

1 に答える 1

1

確かにそうですが、技術よりもアプローチだと思います。あなたがプロジェクトについて説明したことを実装しました(オンラインですが、ここで恥知らずなプラグインを実行したくありません。興味がある場合は、リンクを投稿できます)。私のスタックは、認証とビジネス ロジックの両方に REST API を公開するバックエンドの Java です。クライアントは backbone.js アプリケーションです。セッションをまったく使用しないことを明示的に決定しました。完全にステートレスです。これはもちろん、リクエストごとにユーザーを再認証する必要があることを意味します。

ユーザーがわずかに変更された OAuth エンドポイントを介してログインすると、リクエストごとに渡す必要があるトークンが取得されます。この場合、Cookie はブラウザによって自動的に処理されるため機能します。Cookie として渡されない場合、バックエンドはそれをパラメーターとして期待します。フロントエンドは REST エンドポイントを使用して通信します。これは、単一ページのアプリケーションであり、完全なクライアント側です。これは、バックエンドが、アプリケーション自体であるいくつかの JS ファイルを含む、基本的に空のページを提供することを意味します。他のページロードは発生しません。ログアウトは単に Cookie を削除するか、authToken を送信しないことで行われます。サーバーはユーザーを「忘れる」ことはできませんし、その必要もありません。トークンは、明示的に、またはパスワードを変更することによって無効にできるので便利です。私'

于 2013-06-10T09:06:41.990 に答える