Twitter Provider - handling iOS revoked token

[kornifex]

Hello,

While implementing the Twitter provider, we stumbled upon a fringe issue: our iOS Twitter account was logged in the settings, but revoked on Twitter side (using their web interface).

Both remote calls remoteAccountWithSystemAccount and accessTokenWithSystemAccount occurs at the same time, that led to an issue if an error occurred during the first call. Maybe you should differ the second call in this case.

NSArray *signals = @[
         [RACSignal return:account],
         [self remoteAccountWithSystemAccount:account],
         [self accessTokenWithSystemAccount:account]
];
return [self rac_liftSelector:@selector(dictionaryWithSystemAccount:remoteAccount:accessToken:) withSignalsFromArray:signals];

In our case, the first one returned a 401 HTTP status code with a 89 error code (see Twitter's documentation for a full list of error codes), which should be handled to renew the account's credentials with [ACAccountStore renewCredentialsForAccount:completion:]. Maybe this should even be extended to all 401 and 403 HTTP status codes without checking for specific Twitter error codes.

@amarcadet and I would have liked to help you on this one, but as we're not very fluent with ReactiveCocoa, we were afraid to mess up…

We are open to discuss of this one with you!

[calebd]

Ok, I believe this is something that both the Facebook and Twitter providers need to do. An interesting twist that you noted is the error passing with ReactiveCocoa. Normally, signal composition methods in ReactiveCocoa bubble the error up automatically — that's one of the reasons I like it so much. I believe that rac_liftSelector:withSignalsFromArray: does this as well but I am not completely certain. I'll as a few guys I know that use it a lot.

That aside, calling -[ACAccountStore renewCredentialsForAccount:completion:] with a Twitter account will simply prompt the user to login with their Twitter account in settings again. So this might be an opportunity to build a fallback mechanism, where the system Twitter provider could fallback to the Twitter web provider, should it exist. So in the case of bad credentials, no account, or access denied we could still provide a way to log a user in.