2 Commits

Author SHA1 Message Date
湯本 開
83add51148 Merged PR 538: Azure AD B2Cの結果をCacheManagerにキャッシュするよう修正
## 概要
[Task2967: Azure AD B2Cの結果をCacheManagerにキャッシュするよう修正](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/fa4924a4-d079-4fab-9fb5-a9a11eb205f0/_workitems/edit/2967)

- キャッシュを扱うRedisServiceを追加
- AdB2cServiceでRedisServiceを使って結果をキャッシュする実装を追加
- ADB2Cの呼び出しと、キャッシュからの取得が行われた時にログを出す実装を追加
  - Azure Monitorで呼び出しコストでアラート出したくなった時のための予防的追加
- 開発環境でローカルのredisを操作する用途のredis-cliをインストールする設定を追加&スクリプトを追加
- `getUser` と `getUsers` の返り値の方を統一 & 使用されなくなった方の型を削除
- AdB2Cの`ttl` に設定する用の値を環境変数に追加
  - 今後実装予定のトークンのキャッシュとはTTLを別にしたかったため
- 複数ユーザー削除処理内でのindex処理が不適切と思われる箇所があったので修正

## レビューポイント
- **Redisへのget/set/delが失敗した際に、エラーログだけ出して成功 or 取得対象なしと同様の動作をするように作成したが、問題なさそうか**
    - これは速度向上用のキャッシュが死んでいても業務は動くべきではないか、という考えによるもの
    - 通信できない=障害中であると想定されるので、失敗しても良いような気もするので相談
- **AdB2cService内でキャッシュを扱う箇所のコードの可読性に問題はないか**
    - 更にWrapしてキャッシュの具体的な動きを隠蔽することも考えたが、詳細なエラーの制御をしづらくなりそうだったので具体的な引数の変換等以上のことはしない形で実装
    - AdB2cServiceが十分に末端の処理なので詳細な処理を生で書いていても認知負荷はそう変わらない可能性がある
- **キャッシュする値の性質によってTTLを変えられる仕組みを前提に設計・実装したが、懸念点はないか**
- **TTLに設定する値は妥当そうか**
- **`Aadb2cUser` を削除したが問題ないか**
- **`deleteUsers` 内のログ処理の変更は適切か**
    - to 岩田さん

## 動作確認状況
- ローカルで確認
- npm run testが通過することを確認
2023-10-31 03:45:31 +00:00
makabe.t
41f0213fe9 Merged PR 1: タスク 1359: API実装(認証/IDトークン検証)
## 概要
[タスク 1359: API実装(認証/IDトークン検証)](https://paruru.nds-tyo.co.jp:8443/tfs/ReciproCollection/OMDSDictation/_workitems/edit/1359)

- IDトークンを受け取って内容を検証し、デコードしたペイロードを返すサービスを実装しました。

## レビューポイント
- サービスの処理の流れが認識とあっているか。
- ADB2CのAPI呼び出しを別サービスにしているが問題ないか
- 公開鍵の変換処理を別サービスに切り出しているが構成に問題はないか。
- トークンの検証をエラーごとに処理しているがエラー内容は認識通りか

## UIの変更
- なし

## 動作確認状況
- テストが通ることを確認

# 備考
- IDトークンを検証して中身を返すまでの実装です。
2023-03-07 01:30:13 +00:00