パート1. Angularのクライアント
この記事について
この記事では、このタスクの既成のソリューションを使用せずに簡単な認証を作成する方法を説明します。 AAA（認証、承認、アカウンティング）を書きたい初心者には便利です。 AngularのクライアントリポジトリとSpringのサーバーリポジトリ 。
この記事では、Angularのクライアント側コードの抜粋を作成します。
認証サーバーを使用するクライアント
このセクションでは、クライアントの開発のいくつかの側面について説明します。クライアントのコードは、REST APIを介してサーバーと対話するために処理できます。
プロジェクトの構造を見てみましょう。
. ├── auth # │ ├── actions │ │ └── auth.ts │ ├── auth-routing.module.ts │ ├── auth.module.ts │ ├── components │ │ ├── signin.component.ts │ │ └── signup.component.ts │ ├── containers │ │ ├── signin-page.component.ts │ │ └── signup-page.component.ts │ └── services │ └── auth.service.ts └── core # ├── components │ └── index.component.ts ├── containers │ ├── app.component.ts │ └── not-found-page.ts ├── core-routing.module.ts ├── core.module.ts ├── models │ ├── answer-message.ts │ ├── answer.ts # │ ├── notify-type.enum.ts │ ├── ping-payload.ts # │ └── pong-payload.ts # ├── reducers │ └── reducer.reducer.ts └── services ├── cookies.service.ts ├── ping.service.ts # ├── security.service.ts # , API ├── services.module.ts └── utils.service.ts
認証/承認/登録サービス用のRESTクライアント
サーバーとの通信には、次の階層を持つ@angular/common/http/HttpClient
のゴーストを使用します。
api-base ├── api-security.service └──── security.service
それらには、認証サーバーのAPI
への呼び出しがあります。
さらに、 security.service
サービスからの応答は、階層の下位でauth.service
サービスに送信され、ユーザーの状態をStore
およびCookies
に保存します。 Cookies
は、ページのリロード後に認証済みユーザーを復元するために使用されます。 また、エラーが発生した場合は、コンソールにメッセージを出力して処理し、階層を通過します。
認証方法の例を示します。
authorize(credentials: UserCredentials): Observable<AuthUser | Failure> { return this.securityService.authorize(credentials) // HTTP .pipe( tap(authUser => this.setAuthUserState(authUser)), // catchError(error => { // return this.errorHandler.handleAuthError(error); }) ) }
サーバーペイロード
サーバーにリクエストを送信するには、 HttpClient
のラッパーを使用しますping.service
、Spring API
サーバーAPI
ping
メソッドが呼び出されます。
要求ブレーカー（api-interceptor）
認証されたユーザーに関するデータを送信するには、HTTPリクエストブレーカーを使用します。これにより、AccessTokenとUserSessionがヘッダーに挿入されます。
サンプルコードを示します。
intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> { return this.authService.getLoggedUser() // .pipe( map(authUser => { // let clonedRequest = req.clone(); let isLoggedIn = UtilsService.isLoggedIn(authUser); if (isLoggedIn) { clonedRequest = clonedRequest.clone( { headers: clonedRequest.headers .append(AppConstants.ACCESS_TOKEN_HEADER, authUser.accessToken) .append(AppConstants.USER_SESSION_HEADER, authUser.userSession) } ); } return next.handle(clonedRequest); }), switchMap(value => { return value; }), ); }
サーバー相互作用図
シーケンス図「サーバーとの対話のシーケンス図」は、サーバーへのリクエストを実行するプロセスを示しています。 ページをロードした後、クライアントは認証リクエストを送信します（ここでは、エラーなしで合格した認証のケースを考慮します）。 さらに、この要求を受信した後、サーバーはトークンを発行します。 トークンがそのように発行されるのではなく、承認後に発行されることを明確にする必要がありますが、これはスキームを単純化するために示されていません。 承認の詳細については、関連記事をご覧ください。 次に、サーバー上でトークンを生成した後、応答がクライアントに返されます。 クライアントはこのトークンを保存し、サーバーに対してping
要求を実行します。 サーバーは着信トークンを確認し、 ping
要求データを処理して新しいトークンを生成します。 この例では、単に文字列"${data.getPing()} from ${authUser.getUsername()} and PONG from server"
返します。 サーバーから応答を受信した後、クライアントはトークンを保存し、この新しいトークンを使用して次の要求を実行します。
トークンが失われるか、クライアントがトークンを正しく保存しない場合、このリクエストと次のリクエストは、ユーザーが再び承認されるまで通過しません。
おわりに
この記事では、Angularを使用して簡単な認証クライアントを作成する方法を検討しました。これにより、このバンドルでの作業が簡単になります。