Użycie TokenAuthenticator
odpowiedzi like @theblang jest poprawnym sposobem obsługi refresh_token
.
Oto moje narzędzie (ja używam Kotlin, Dagger, RX ale możesz wykorzystać ten pomysł na implementację do swojego przypadku)
TokenAuthenticator
class TokenAuthenticator @Inject constructor(private val noneAuthAPI: PotoNoneAuthApi, private val accessTokenWrapper: AccessTokenWrapper) : Authenticator {
override fun authenticate(route: Route, response: Response): Request? {
val newAccessToken = noneAuthAPI.refreshToken(accessTokenWrapper.getAccessToken()!!.refreshToken).blockingGet()
accessTokenWrapper.saveAccessToken(newAccessToken) // save new access_token for next called
return response.request().newBuilder()
.header("Authorization", newAccessToken.token) // just only need to override "Authorization" header, don't need to override all header since this new request is create base on old request
.build()
}
}
Aby zapobiec cyklowi zależności, jak komentarz @Brais Gabin, tworzę 2 interfejsy, takie jak
interface PotoNoneAuthApi { // NONE authentication API
@POST("/login")
fun login(@Body request: LoginRequest): Single<AccessToken>
@POST("refresh_token")
@FormUrlEncoded
fun refreshToken(@Field("refresh_token") refreshToken: String): Single<AccessToken>
}
i
interface PotoAuthApi { // Authentication API
@GET("api/images")
fun getImage(): Single<GetImageResponse>
}
AccessTokenWrapper
klasa
class AccessTokenWrapper constructor(private val sharedPrefApi: SharedPrefApi) {
private var accessToken: AccessToken? = null
// get accessToken from cache or from SharePreference
fun getAccessToken(): AccessToken? {
if (accessToken == null) {
accessToken = sharedPrefApi.getObject(SharedPrefApi.ACCESS_TOKEN, AccessToken::class.java)
}
return accessToken
}
// save accessToken to SharePreference
fun saveAccessToken(accessToken: AccessToken) {
this.accessToken = accessToken
sharedPrefApi.putObject(SharedPrefApi.ACCESS_TOKEN, accessToken)
}
}
AccessToken
klasa
data class AccessToken(
@Expose
var token: String,
@Expose
var refreshToken: String)
My Interceptor
class AuthInterceptor @Inject constructor(private val accessTokenWrapper: AccessTokenWrapper): Interceptor {
override fun intercept(chain: Interceptor.Chain): Response {
val originalRequest = chain.request()
val authorisedRequestBuilder = originalRequest.newBuilder()
.addHeader("Authorization", accessTokenWrapper.getAccessToken()!!.token)
.header("Accept", "application/json")
return chain.proceed(authorisedRequestBuilder.build())
}
}
Na koniec dodaj Interceptor
i Authenticator
do swojego OKHttpClient
podczas tworzenia usługi PotoAuthApi
Próbny
https://github.com/PhanVanLinh/AndroidMVPKotlin
Uwaga
Przepływ uwierzytelniania
- Przykładowy
getImage()
kod błędu API zwrócił 401
authenticate
Metoda wewnątrz TokenAuthenticator
zostanie zwolniona
- Synchronizuj
noneAuthAPI.refreshToken(...)
wywołane
- Po
noneAuthAPI.refreshToken(...)
odpowiedzi -> nowy token zostanie dodany do nagłówka
getImage()
wywoła AUTO z nowym nagłówkiem ( HttpLogging
NIE BĘDZIE zarejestrować tego połączenia) ( intercept
wewnątrz AuthInterceptor
NIE BĘDZIE WYWOŁANE )
Jeśli getImage()
nadal nie powiodło się z błędem 401, authenticate
metoda wewnętrzna TokenAuthenticator
zostanie uruchomiona PONOWNIE i PONOWNIE, a następnie wiele razy ( java.net.ProtocolException: Too many follow-up requests
) wyrzuci błąd dotyczący wywołania metody . Możesz temu zapobiec, licząc odpowiedź . Przykładowo, jeśli return null
w authenticate
po 3 razy powtórzyć, getImage()
będzie skończyć ireturn response 401
Jeśli getImage()
odpowiedź zakończy się sukcesem => otrzymamy wynik normalnie (jak dzwonisz getImage()
bez błędu)
Mam nadzieję, że to pomoże