BoilerplateJSセットアップで、承認と認証を処理するための推奨される方法は何ですか?
明らかに、サーバー側では、Cookie などをチェックして、誰がログインしているかを確認します。しかし、クライアントでは、ユーザーがログインしているかどうか、およびそのユーザー名などをどのように知ることができますか?
BoilerplateJSセットアップで、承認と認証を処理するための推奨される方法は何ですか?
明らかに、サーバー側では、Cookie などをチェックして、誰がログインしているかを確認します。しかし、クライアントでは、ユーザーがログインしているかどうか、およびそのユーザー名などをどのように知ることができますか?
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 への後方参照が含まれているため、ユーザーは認証後に元のページにアクセスできます。