Question: Can't retrying be avoided?

[eimermusic]

Hi, I just started playing with this on a project and was wondering why the refresh mechanism relies on the retry mechanism for a "failed" request? Is this a limitation of Alamofire?

I am not super-comfortable with relying on a 401. It would be nice to be able to log Oauth-related failures without having to supress a ton of expected credential failures server side.

Tokens are (often, and certainly in my case) JWT tokens. So, i know before making a request wether or not the access token is valid or expired. The problem seems to be that adapt() for RequestAdapter is not terribly compatible with an async http request.

If you have the time to answer, I am curious.

[phimage]

You cannot know if your token is really valid. The server could invalid your token.

• In oauth2 you can launch a revoke token request
• administrator or you can revoke the token

So even if you are able to implement a refresh before receiving the error, you must implement this "retry case"

Yes relying on 401 only is not good There is here an extension to check the server error https://github.com/OAuthSwift/OAuthSwift/blob/master/Sources/NSError%2BOAuthSwift.swift You can see for instance that facebook use 400, not 401

Then it's not the RequestAdapter but the RequestRetrier protocol to mange this

[eimermusic]

Good point. Thanks for explaining.

Just more context: In my case, I am controlling the API server as well and know that the 1/1000 case will be a intentionally invalidated token. Whereas an expired token is the norm.

My main concern is flooding the server with errors, being forced to suppress Oauth errors server side and having no visibility into any actual issues with Oauth. This could partly be developer OCD, It just feels more neat and tidy to not lean so heavily on retries.

Also 😄 , doing 2 requests rather than 3 is noticeably faster.