rdioDidAuthorizeUser not being invoked after a [rdio authorizeUsingAccessToken:AFOAuthCredential] call

[yourei]

Hi - I updated my framework to the latest and switched over to OAuth 2.0. Everything seems fine when I login fresh and try to get playlists using the rdio authorizeUsingAccessToken method. But, after an hour or so it just stops working and when I try to invoke the authorizeUsingAccessToken by passing in the saved AFOAuthCredential, it never goes to the delegate methods of didAuthorize or didFailed. Sometimes, I get a rather unusual error saying that it is an invalid_grant and the User ID is removed from the account store. But, the same code and setup works when I login fresh and use the saved credential for an hour.

I essentially do a rdio authorizeUsingAccessToken and then make the rdioRequest using callAPIMethod in the rdioDidAuthorizeUser method with a success/failure block.

Please let me know if there are any issues on the server side at this moment?

Appreciate your help!

[yourei]

As a follow up, I have been debugging this for a few days now and I think what is happening is that the refresh_token in the saved AFOAuthCredential gets set to null. Then after that, subsequent calls to the Rdio API fails after that and I can't renew the OAuth2 session because I don't have the refresh_token anymore.

Any ideas?

[yourei]

I was able to get around this by doing what @ungureanuli did with his OAuth2 issue. I renew the tokens separately outside of the SDK, then create the AFOAuthCredential object using those tokens. An interesting observation here is that if I save the AFOAuthCredential object itself (since the object implements NSSecureEncoding), the refresh token seems to be set to null at some point by some process that I am not aware of. However, if I create the AFOAuthCredential object manually with the saved tokens I am able to refresh the tokens.

[yourei]

I keep getting this error now:
-RDSession loginWithOAuth2Credential:: Login already in progress

The rdioDidAuthorizeUser method never gets called again, until I manually login again. Is anyone from Rdio looking at this? Can I please get a response or confirmation if this is a bug?

Thanks!

[jaredsinclair]

Yep. I've been experiencing this same issue, too.

Steps to Reproduce

1. Log in for the first time using a web browser and the OAuth 2.0 flow.
2. Initialize a valid AFOAuthCredential with the received data.
3. Invoke authorizeUsingAccessToken: passing the credential from Step 2.
4. Success. Rdio invokes rdioDidAuthorizeUser: on the delegate. So far, so good. We can initialize a shared player, make API requests, the whole bit. Note: I store my AFOAuthCredential in the Keychain via the provided methods in AFOAuth2Manager. My credentials always have a non-nil refresh token when I need one.
5. Wait 12 hours for the credential from Step 2 to expire. Meanwhile the app has been closed.
6. Launch the app again.
7. Pretend you don't know the credential is probably expired and call authorizeUsingAccessToken:.
8. What should happen next is the SDK either immediately (or after a delay awaiting a network callback) should notify the delegate rdioAuthorizationFailed:. Instead there is no callback.

Things I’ve Tried

I’ve tried calling authorizeUsingAccessToken: again after a 5 to 10 second delay without a response. Doing this leads to the following warning in the console:

2015-08-23 10:45:06.958 Rotation[47844:2432955] -[RDSession loginWithOAuth2Credential:](177): Login already in progress

Further, quitting and relaunching the app and trying the above steps again leads to repeat occurrences of that console log. It's as if the Rdio SDK has cached the previous login state to disk and refuses to accept further requests, even though after a force quit there are no inflight authentication requests. At this point my only recourse is to force the user to log out and then sign back in again.

Workarounds

There is only one workaround. Since I can't try to force a repeat authorization without forcing the user to sign out, I have to force the app to abort() so that the user will launch it again and (this time) achieve a successful reauthentication. That bears iteration: repeating the above steps after a force quit leads to a successful flow.

This is a show-stopper bug for me. I may have to scrap my whole project because of this issue. :-(

[jaredsinclair]

Update: Shit. I think I may have identified a possible bug on my side leading to this. I'm not sure yet, but I'll follow up in a couple days when I have more info.

[jaredsinclair]

(Yay, 12 hour wait times btwn bugs).

[jaredsinclair]

Update: Alas, the bug I identified in my code did not affect this issue. So, yes, this is a show-stopping bug that if unfixed will mean I have to scrap my entire project. :-/

[jaredsinclair]

I have even tried anticipating the expired credential, refreshing it, and then using the refreshed credential to authenticate the user. This leads to the same behavior as trying with an expired credential. The first call to authenticate the existing user with a credential (expired or not) never leads to a delegate method callback. Neither the success nor the failure callback is called.

[jaredsinclair]

Any word on this?

[yourei]

I have done the same thing and still experience the issue. I haven't heard back from anyone at Rdio sadly. If any of the devs is looking at this, please give us any alternate suggestions or a fix as this is a show stopper for me as well.

[dasevilla]

I've been able to reproduce this issue and I'm now investigating a fix. No ETA yet

[yourei]

Any word on this with an ETC? Thx.

[dasevilla]

This is fixed as of v3.1.0

[jaredsinclair]

Woo-hoo! I look forward to trying this out.

[jaredsinclair]

Will the fix apply retroactively to existing credentials created using 3.0.x versions of the framework, or will new credentials have to be created using 3.1.0? I tried launching a build using 3.1.0 on a device with expired 3.0.x credentials (only a couple hours old) and the bug returned. I'll keep testing, but it will be another 12-24 hours before I can tell you more.

[jaredsinclair]

BTW: I also opened a PR: rdio/hello-ios-playback#14 to enable Swift import support.

[yourei]

I am testing as well. Will post back if it fixes it for me. Thanks a lot for following up on this @dasevilla. Appreciate it!

[jaredsinclair]

Unfortunately the issue is still happening for me using 3.1.0.

[ungureanuli]

Hello jaredsinclair. A possible workaround for your problem is to try, before calling the authorizeUsingAccessToken: method, something like:
[AFOAuthCredential deleteCredentialWithIdentifier:@"services.rdio.com"];
Call this even before setting the RdioObject.delegate (because the stored tokens will be automatically loaded by rdio).

[ungureanuli]

Hello yourei. A possible workaround may be to logout and destroy the RdioObject, delegates, RdioPlayer... and start again the login flow (also have in mind the above suggestion when you start the login flow).