code reading of Authorization in bulletproof-react
![habakan](https://res.cloudinary.com/zenn/image/fetch/s--ouYC3D7M--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/489371bbff.jpeg)
認証周りの整理
- パイプライン確認
- 認証の責任範囲の分割方法
- テスト
![habakan](https://res.cloudinary.com/zenn/image/fetch/s--ouYC3D7M--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/489371bbff.jpeg)
パイプライン確認
ルートコンポーネント
./routes/index.tsxにて、useAuthによりauth情報を取得している
useAuthはinitReactQueryAuthにより、返されたもの
最終的にはreact-query-authライブラリを利用している
ルーティング
Usersページの場合はfeatures/routes/User.tsxにてAuthorizationコンポーネントをレンダリングしてる
AuthorizationでuseAuthを利用したチェックと、それに伴うレスポンスfallcallbackなどが実装されている
おそらくPriveateなルーティングページはこのAuthorizationをコンポーネントとして記述している
![habakan](https://res.cloudinary.com/zenn/image/fetch/s--ouYC3D7M--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/489371bbff.jpeg)
認証の責任範囲の分割方法
認証により変更する部分は、ルーティングのページとAPIのレスポンス
どちらもuseAuthを利用して処理をするが、APIレスポンスなどの処理についてはlib/Authorizationで実装して参照するような形となっている
実際の内部処理については、features/auth/apiなどでAPI経由で実装している
lib/authではAPIのリクエストやレスポンスのハンドリングをReact APIとしてwrapしている
lib/authとlib/authorizationの違いとして、lib/authorizationではauth情報のroleを利用した制御をしている
ここを分けた理由としては、ハンドリングのinterfaceとしてreact-query-authで渡したいということもある
![habakan](https://res.cloudinary.com/zenn/image/fetch/s--ouYC3D7M--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/489371bbff.jpeg)
テスト
lib/tests/authorization.test.tsxでテストしている
lib/authはテストが実装されていなかったが、APIの処理をwrapして、レスポンスを型で制御できているからあまりテストするところがないという判断?
authorization.test.tsxはcreateUser内でfakerを通してUserデータを作成してテストしている
賢いなと思ったのは、Expected TextをAuthorizationの子コンポーネントととして渡し、無事アクセスできているかどうかをscreen.getByTextでTestしている
- Role(ADMIN, USER)の違いによる認可の違い
- Policy(Roleだけでなく、コメントの筆者かどうかで削除するかなど)の違いによる認可の違い