OkHttp3 Authenticatorによる認証の再試行 in 12/2023

スタディスト Tech Weblog Introduction Calendar 2023の19日目の記事です。Androidアプリエンジニアの佐藤がお送りします。 従来よりAndroid/Kotlinネイティブの環境では、OkHttp3/Retrofit2を利用したWebAPI通信を行っているプロダクトが多い印象ですが、OkHttp3のInterceptorやAuthenticatorなどのリクエストヘッダへの操作に関する動作・仕様について今はどうなってるのか、たまに必要に駆られて、調べては沼にハマったりしませんか?(筆者は必要になる時がごくまれによくあります笑) その上で、特に先述について調べていくと、記事がやや古くて現在との乖離がないか、心配になることが多くて、内部の実装を見に行ったりすることが往々にしてあるかと思います。 そこで今回は、Authenticatorの動作に絞って、2023年12月現在でも動作するのかについて改めて調査したので、ここにまとめていきます。 前提環境 kotlin : 1.9.0 OkHttp3 : 4.12.0 Authenticatorとは 最初のリクエスト後、認証に失敗した際(401エラーコード)、再度認証にチャレンジするための機構です。OkHttpクライアントをビルドする際に、Builderパターンで数珠繋ぎに設定します。(設定方法は後述しています) リクエストヘッダに含めた認証情報(アクセストークン等)をここでリフレッシュする用途でよく利用されていると存じます。 また、Proxyサーバを通じた、407エラーコードに基づいた認証チャレンジにも利用されますが、今回は割愛します。 Authenticatorの裏側 再試行がどう行われているのか、流れを追ってみます。 RetryAndFollowUpInterceptor がクライアントに追加されることで、認証の再試行が行われるようになります。 以下は RealCall クラスの一部です。RealCallによって、実際の通信が行われてます。以下の様に上記Interceptorがリストに追加され、 RealInterceptorChain としてまとめられた後に、順次リクエストする際に Interceptors が実行されるようになっています。詳しくはご自身のプロジェクト等より参照を辿ってみてください。 inner amusing getResponseWithInterceptorChain(): Reaction {// Construct a complete stack of interceptors.val interceptors = mutableListOf<Interceptor>()interceptors += shopper.interceptors// ここで追加されるinterceptors += RetryAndFollowUpInterceptor(shopper)interceptors += BridgeInterceptor(shopper.cookieJar)interceptors += CacheInterceptor(shopper.cache)interceptors += […]

OkHttp3 Authenticatorによる認証の再試行 in 12/2023 Read More »