[Question] Refresh token logic concerns

[minhnimble]

It is great to see you utilize the Interceptor to intercept every request and apply the refresh token logic 👍. Now, I have a small concern that you are determining when to trigger the refresh by calculating the expiration time based on the device's system date and via the expiresIn calculation. I am curious on why you choose to implement the refresh token logic like this approach? And how would you solve the issue when user alters the device's time to make the token check here always passes but the token is actually expired (server will return 401 code here) and the user is still active on the current session?

• Trigger refreshing token on intercept: https://github.com/hsu-hsu/nimble-survey-app/blob/81c798e104ee3a1fa125d72e060540d0ac316a86/app/src/main/java/com/nimble/android/api/interceptors/AuthInterceptor.kt#L31-L54

• Refresh token check logic: https://github.com/hsu-hsu/nimble-survey-app/blob/81c798e104ee3a1fa125d72e060540d0ac316a86/app/src/main/java/com/nimble/android/utils/SessionManager.kt#L12-L16

[hsu-hsu]

In refresh token logic, I thought the value in expire in is the amount of time that will expire from the current. So, I also took system current time in millisecond and plus the expire in value to that time and save that total value to shared preferences. And I compare current millisecond and the millisecond I store in share preference so I assume that it will save even user change the device's time.

But, there is one thing to consider that if user change device’s time after the application saved expire time then it will throw an error and clear data from the preference and user will need to login again.

And, also with my logic in AuthInterceptor class, however user change device's time, it will only call api at the first time but after that when server return error about the token, it will clear the data and request the user to login again.