3

BoilerplateJSセットアップで、承認と認証を処理するための推奨される方法は何ですか?

明らかに、サーバー側では、Cookie などをチェックして、誰がログインしているかを確認します。しかし、クライアントでは、ユーザーがログインしているかどうか、およびそのユーザー名などをどのように知ることができますか?

4

1 に答える 1

6

BoilerplateJS を使用したプロジェクトの 1 つでこれがどのように行われたかを共有します。このプロジェクトでは、認証に OAuth 2.0 を使用しました。

  • BoilerplateJS または複雑な JS を使用していない別のログイン ページがありました。別々にしておく理由は、認証が URL リダイレクトに依存する可能性があるためです。これは、JS では適切に処理されません。

  • ユーザーが正しく認証されると、サーバー セッションの auth_token を受け取り、それを JS 変数として保存します。このトークンを格納するために、グローバル Boiler.Context の「設定」を使用しました。設定は子コンテキストに継承されるため、どこからでもアクセスできました。

  • 次に、認証のために、認証されたアクセス キーを含む、ログに記録されたユーザーの単純な ACL をダウンロードしました。これらのキーは、クライアントの検証でコントロールを表示/非表示にするためだけのものでした。バックエンド サービスで実際の承認が実行されました。

  • BoilerplateJS コンポーネントは、認証を含めて完全に自己完結型である必要がありました。したがって、特定のコンポーネントのビューモデルがサーバーから不正な 401 HTTP 応答を受信した場合 (ログインしていないか、セッションの有効期限が切れているかのいずれか)、ユーザーをログイン ページにリダイレクトせずに、そこでコンポーネントを別の方法でレンダリングしました。

  • リダイレクトしなかったため、BoilerplateJS コンポーネントがコンテンツをアクティブに表示していなくても、ユーザーはページ上の他の情報を利用できました。再ログインへのリンクを含む、コンポーネントに関するいくつかのエラー情報をレンダリングしました。

  • これの処理は、私たちが作成した一般的なエラー ハンドラーを介して行われました。component.js から、ビューモデルにエラー コールバック関数を渡します (コンテキスト自体にもこれがある場合があります)。このコールバック関数は、ビューモデル内で発生したエラーを通知するためにビューモデルによって使用されます。401 HTTP コードの場合、このハンドラーが呼び出され、component.js にエラー情報と再ログインへのリンクを含む UI をレンダリングするように要求します。

  • ユーザーが再ログイン URL をクリックして、ログイン ページに戻ります。この URL には元の URL への後方参照が含まれているため、ユーザーは認証後に元のページにアクセスできます。

于 2012-09-24T05:48:01.310 に答える