Closed4

code reading of Authorization in bulletproof-react

habakanhabakan

パイプライン確認

ルートコンポーネント

./routes/index.tsxにて、useAuthによりauth情報を取得している
useAuthはinitReactQueryAuthにより、返されたもの
最終的にはreact-query-authライブラリを利用している

ルーティング

Usersページの場合はfeatures/routes/User.tsxにてAuthorizationコンポーネントをレンダリングしてる
AuthorizationでuseAuthを利用したチェックと、それに伴うレスポンスfallcallbackなどが実装されている
おそらくPriveateなルーティングページはこのAuthorizationをコンポーネントとして記述している

habakanhabakan

認証の責任範囲の分割方法

認証により変更する部分は、ルーティングのページと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で渡したいということもある

habakanhabakan

テスト

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だけでなく、コメントの筆者かどうかで削除するかなど)の違いによる認可の違い
このスクラップは2022/07/06にクローズされました