はじめに
開発部の 有澤 です。
普段、WebアプリのAPIを開発する際に、Symfony Security の FireWall で保護された API に対して HTTPクライアント (cURL、Postman、HTTPie など) でデバッグしたいことがありませんか？
sensio/framework-extra-bundle を使用している場合は @IsGranted アトリビュート を手元の環境で外したりするのはありがちですが、
コミットしたい変更とは違う diff が出てくるので、開発中にモヤモヤしがちです。
また、@IsGranted アトリビュート を外した後、開発者によってはCLIツールで叩く流派であったり、GUIツールで叩きたい流派であったりと、
開発者によって API を叩く際のユースケースは変わりがちです。
さらに、API の認可仕様が OAuth 2.0 だった場合、なんらかの方法で Bearer Token を取得したあと、 HTTPリクエストに「Authorization: Bearer BEARER_TOKEN」のようなヘッダーを加えなければならない仕様なので、デバッグするためにわざわざトークンを取得するのは面倒です。
そこで、本記事では symfony/security-bundle と hwi/oauth-bundle に依存した方法ではありますが、
独自の認可を作って、APIへアクセスしやすくします。
当然ですが、ローカルでAPIを利用する際の話なので、間違ってもステージング環境やプロダクション環境では適応しないでください。
依存
- Symfony 6系
- symfony/security-bundle 6系
- sensio/framework-extra-bundle 6系
- hwi/oauth-bundle 6系
デバッグで利用する認可を実装する
実装した Authenticatorクラス は以下です。
GitHub - iamyukihiro/fake_auth (FakeAuthenticator)
この FakeAuthenticatorクラス はデバッグの時のみに使用する認可仕様を実装しています。
実装を説明すると HTTPヘッダーから「username」値を取得し、データベース上から該当する user.username を検索し、 存在すれば「そのUserで認証する」処理を書いています。
そのため、HTTPクライアントは User が持つ username プロパティを知っていれば、認可が通ります。
ちなみに、プロダクション環境で OAuth 2.0 で保護したい場合は、以下の OAuthAuthenticator を使用します。 独自実装した FakeAuthenticator と比較すると、認可サーバーが発行したアクセストークンを変数に代入している実装が加わっていることがわかります。
GitHub - hwi/HWIOAuthBundle (OAuthAuthenticator)
まとめ
以下の GitHub Repository で、デバッグしやすくしたWebアプリを載せています。 このクラスをどう設定すれば良いかわからない場合、閲覧いただくとわかると思います。
GitHub - iamyukihiro/fake_auth
また、実際に保護するリソースとしてhttps://127.0.0.1:8000/api/chart を指定しています。
APP_ENV の値によって、利用する Authenticatorクラス を差し替える実装を行ったので、
応用する際に閲覧したり、Webアプリを動かしてみて、環境ごとにインジェクションが変化している様子を閲覧いただけたら嬉しいです。