1

I have added Dropbox support to my apps a while ago and never touched the implementation since. It is still running fine. However, a few month ago Dropbox updated the way permissions are handled which may require code changed in my apps. As explained by Dropbox I have to check if my apps work with short-lived access tokens.

The Dropbox docs describe the necessary changes when using their API directly but I use different versions of their official SDK in my apps:

  • iOS: ObjectiveDropboxOfficial 3.1.2
  • macOS: ObjectiveDropboxOfficial 2.0.6
  • Android: dropbox-core-sdk 3.0.6

As said, I have not changed or updated the Dropbox code in my Apps for a while. Newer versions of the SDKs are available and I will update them soon. However, I am not sure how to test, if the existing versions of my apps, using these SDK version support short-lived access tokens or not. How can I test this?

I have only configured the SDK code (provided the API key, etc.) and all API calls, tokens, etc. are handled by the SDK. How do I find out, if these SDK version work correctly work with the updated API?

Andrei Herford
  • 17,570
  • 19
  • 91
  • 225

1 Answers1

1

The official Dropbox SDKs have been updated to support short-lived access tokens, as of v5.0.2 for the Dropbox Objective-C SDK, and v3.1.0 for the Dropbox Java SDK.

You should update to the latest versions and then update your code to use the latest methods for the authorization flow as covered here for the Objective-C SDK and here for using the Java SDK in an Android app.

Once you've done so, you should test the full app authorization flow by signing out and signing back in again, in each version of the app, along with whatever other testing you would normally do.

Greg
  • 16,359
  • 2
  • 34
  • 44
  • Sounds unbelievable, but while using the latest Dropbox SDK for Android with a short-lived tokens account, my app works great even after the mentioned 4 hours from the initial authorization. No code changes were made on my side. Does Dropbox SDK do all the job under the hood by itself? – Orange Apr 12 '21 at 09:13
  • Update: Checked the example and found out that the entire authentication flow should be changed to work with SLT (short-lived tokens). It seems that my app continues to work with LLT(long-lived tokens) even after changing auth type to SLT in the Dropbox dev console. How end-users should migrate from LLT to SLT? Or is explicit reauthentication required? – Orange Apr 12 '21 at 09:48
  • 1
    @Orange Yes, the short-lived tokens implementation in the official Dropbox SDKs includes the use of refresh tokens, so that they will automatically perform refreshes to get new short-lived tokens as needed. And existing long-lived access tokens will also continue to work. Existing users can explicitly re-authorize the app to switch to shot-lived access tokens (and refresh tokens) but it is not strictly necessary. – Greg Apr 12 '21 at 14:18
  • thanks for the reply. I debugged the code and confirm that Dropbox SDK refreshes the SLT by itself. The only thing I wish (and probably it will be convenient for other users of Dropbox SDK) - to get notified about when the SLT was refreshed, in order to store the updated info. "... but it is not strictly necessary" - What will happen after 30 SEP 2021 to those users, who didn't switch to SLT? – Orange Apr 13 '21 at 09:44
  • @Orange Can you elaborate on what you mean when you say you want "to get notified about when the SLT was refreshed, in order to store the updated info"? The SDK should handle all of that for you. – Greg Apr 13 '21 at 14:17
  • 1
    @Orange After the change, any existing long-lived access tokens will continue working as before. Any users still using an old version of the app, not updated for short-lived access tokens/refresh tokens, will only receive a short-lived access token if/when they process the app authorization flow after the change. – Greg Apr 13 '21 at 14:18
  • I mean background access. As I can see the credentials could be gotten on the explicit authorization stage only. And there is no possibility to get the updated credentials after STL is refreshed. – Orange Apr 13 '21 at 19:44
  • 1
    @Orange In the Dropbox Objective-C SDK, the SDK will automatically handle the credential storage for you. In the Dropbox Java SDK on Android, you should just store and re-use the refresh token. The refresh token doesn't change with each refresh, so you can just re-use that. You don't need to store the new short-lived access token each time. – Greg Apr 13 '21 at 20:17