Add support to refresh the token on expiry

[alvins82]

Currently if the token expires - no check is made before to make sure the token is not expired.

It should check for expiration before making the request - if expired - use refresh token to get a fresh access token.

• Note - I am not sure if this is how it should work. e.g. It could be left up to the developer to check before each call is made using AFOAuth2 but would be useful if this was handled by the framework.

[conradev]

There are two ways to use AFOAuth2Client currently.

The first is to subclass from AFOAuth2Client and then use it as your API client. The second is to use AFOAuth2Client from another AFHTTPClient to do the authentication. Adding support to AFOAuth2Client to auto-refresh the token would require that the first way be used, and that is not always possible. You cannot inherit from AFOAuth2Client if you are using an AFRESTClient, or if the OAuth2 endpoints do not share a Base URL with the rest of the API.

In addition to that hurdle, there are many practical issues with the implementation of auto-refresh. The first is that there is no reliable, global position to check for token expiry. There is no reliable way to intercept all operations being added to the operation queue, and there is no way to run code before each operation runs. There is KVO, but KVO is not meant for writing code to intervene, but rather, to observe. It is possible to intercept all operations as they are created, but that is at a disconnect with when the operation would actually run, which is an important factor when dealing with expiration.

On top of that, if you determine that an operation is about to run, about to send a request with an expired token, what do you do? You can halt the operation and refresh the token, but now what? You would need a way of injecting the new token into the request of the pending operation(s), something that is not possible with the current API.

I managed to do it here, but that implementation has its share of hackery..

[booiiing]

I am currently confronted with this issue and thinking about extending enqueueHTTPRequestOperationWithRequest:success:failure. The failure-block would check for an expired token or invalid_token in the server-response, refresh the token (if possible) and enqueue the request again.

I will let you know how that works out for me and maybe pull-request it in if the code is good enough.

[booiiing]

As you can see from my recent pull-requests, I found a way to implement this. Alas, it requires some significant changes to the original code. I do, however, believe that those changes make using the client easier, even if automatic refreshing is not pulled in.

[mattt]

To close the loop on this, the best solution I've found for dealing with this is to use dependent NSOperations to check for a valid, un-expired token before any outgoing request is allowed to go through. At that point, it's up to the developer to determine the best course of action for refreshing the token, or acquiring a new one in the first place.