You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Attempt to relink Dropbox? keeps recurring
I updated my iOS app to use the latest Dropbox SDK over the weekend, and initially it seemed fine. But now I notice that whenever I go someplace new and reopen my app, it says my Dropbox account is ...
Greg-DB
Dropbox Staff
Dropbox StaffBob S.15 Thanks for following up with the additional information. As you found, Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here. (We did send notice of this migration by email, but it sounds like those emails may not have made it to you.)
The 'expired_access_token' error indicates that the call failed because it was made using an expired short-lived access token. Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. (You can find more information in the OAuth Guide and authorization documentation.)
The official Dropbox Objective-C SDK will actually handle this for you automatically as long as you set up the authorization flow as documented (that is, using authorizeFromControllerV2 and not authorizeFromController). That is, it will request and store the refresh token for you automatically, in addition to the access token. You don't need to do anything differently to handle those. You should just continue using the supplied authorizedClient and it will handle the refresh process for you.
Checking if authorizedClient is nil is still a valid way to see if you have a client, but that doesn't tell you if the stored token is still valid on the server (just like with previous long-lived access tokens which may have been revoked by the user remotely). If you're getting 'expired_access_token' from an existing authorizedClient, that's likely because it was retrieved using authorizeFromController instead of authorizeFromControllerV2. You would need to unlink and relink with authorizeFromControllerV2 to get a client with a stored refresh token to have that handled automatically.
(For reference, while the creation of new long-lived access tokens is now deprecated, we don't currently have a plan to disable existing long-lived access tokens. If that changes, we will of course announce that ahead of time. That being the case, you can continue using existing long-lived access token(s) without interruption, if you have any. Also, note though that after the change you won't be able to create new long-lived access tokens. While the change began on September 30th 2021, we released it gradually, so you may not have seen your app(s) affected until more recently. Once it applies to your app, it would apply regardless of the "Access token expiration" setting for your app, and that setting may no longer be available for your app.)
And regarding the "An error occurred authorizing your app" error, have you migrated your app registration(s) to scopes yet? You can do so via the "Permissions" tab on the app pages on the App Console. You'll need to do so before you can use the new authorizeFromControllerV2 method. (Apologies for the generic error message! I'll ask the team to improve that.)
Thanks for the reply. I did change to the V2 version of authorizeFromController, but I did not manually Unlink and relink. Users will not know to do that.
If getCurrentAccount failed, should I check to see if the message is "expired access token" and then have my app unlink them?
I don't know anything about scopes - this is something I need to do on my Dropbox app control panel? Before I can use the v2 function at all? Looking at that link, it looks like my apps already have the permissions they need. But you're saying I still need to do something on the panel? Migrate the settings IU guess? If I do that, will it break things for existing users currently?
- Greg-DB
Yes, if you have any users currently or recently using authorizeFromController, they would be receiving only short-lived access tokens, so you may want to catch that error and prompt them to reauthorize the app using authorizeFromControllerV2 instead in order to get a refresh token.
And yes, you can migrate existing app registrations to be "scoped" using the "Permissions" tab of the app's page on the App Console. That's recommended as it allows more granular control over which pieces of API functionality the app can/can't access. That won't affect any existing access tokens or refresh tokens. You can find more information about that here. Alternatively, you can just pass nil to the scopeRequest parameter on authorizeFromControllerV2 instead.
So, I migrated my account. And when passing 'nil' for the scope argument, I can unlink, then relink, and it works.
If I want to start using the scope argument then I just need to figure out which scopes I'm using and pass them all there when I call authorize?
- Greg-DB
You can pass the scopes explicitly to the scopeRequest parameter on authorizeFromControllerV2, but it's not technically required. Once you've migrated an app to scopes, the scopes you have selected will be the default and maximum scopes that can be used by that app. If you pass pass nil to the scopeRequest parameter on authorizeFromControllerV2, it will default to that set of scopes. You can also set the scopeRequest parameter on authorizeFromControllerV2 to take a subset of those scopes if/when that makes sense for your app (e.g., if it only needs to use a subset of that functionality in any particular scenario).
As a security best practice, you should enable only the specific scopes necessary for all of the functionality used by your app.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
