Child Item

Migrating App Permissions & Access Tokens

Hi there,

I have an Android app which uses a dedicated Dropbox folder. I just want to check that when I use the App Console to migrate to the new SLT model, the current access tokens that my users have will still work - is that correct? And I can then decide when to 'flip the switch' in my Android app's code to use the new SLT model? So in fact I can be using the SLT model myself for testing purposes, while my users are still on previous version of my Android app which uses the old model and their current access tokens still work?

Thanks,

Malcolm

Find more posts tagged with

API

Abuse

Comments

malbry

Adding to my previous message. I guess one problem is that as soon as I migrate to use SLT, any *new* users of my currently-published Android app won't be able to authenticate to Dropbox. So that puts me under some time pressure to test and publish an updated version of my Android app - which is not ideal.

Greg-DB

Long-lived access tokens are now considered deprecated, but 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, your users can continue using their existing long-lived access token(s).

And yes, you can test your code with short-lived access tokens while the actual users of your app still use the existing long-lived access token flow. To do so, keep your "Access token expiration" setting on "No expiration", but set 'token_access_type=online' on /oauth2/authorize in your development code to explicitly request a short-lived access token. If using the official Dropbox Java SDK on Android in particular, refer to this example code to see how to switch between these options.

You can refer to the 'token_access_type' field documentation for /oauth2/authorize and Android Auth documentation for the Dropbox Java SDK in particular, as well as this post for more information.

Also, you don't have to change your "Access token expiration" setting before September of next year unless you want to, so you can update your app and wait for most of your users to update to the new version. And for any users on the old version when the change occurs, they'll still receive an access token when processing the app authorization flow, but it will just be short-lived instead of long-lived.

malbry

Thanks for the reply Greg. I had already incorporated the new authentication code in my app in test using the Android template you linked to. The new code works perfectly when the USE_SLT flag is set to FALSE - as you'd expect, because it's just replicating the current workflow. But when I set the USE_SLT flag to TRUE, it takes me to the Dropbox authentication page and that repeatedly fails with a 'no internet connection' message (yes, there is internet). I assume this is because I haven't migrated my app yet on the App Console - is that right?

Greg-DB

That particular error message doesn't sound expected. Can you share a screenshot? Also, if that's occurring in the browser, please share the URL of the page that's failing. Or, if that's occurring in the official Dropbox Android app, please share the version of the the official Dropbox Android app you have installed. Thanks!

malbry

Hi Greg,

This is happening when I execute the following line in my Android app:

Auth.startOAuth2PKCE(context, app_key, DbxRequestConfigFactory.getRequestConfig(), scope);

I attach 2 screenshots below, the first when my app asks to authenticate (using the above code) and the second when I tap 'Allow' which is when the error happens. I think these screenshots are from Android webview rather than via the Android Dropbox app (which is version 214.2.6). I can't get the URL from Android webview as it is not shown to the user. This is running on a Samsung S10e with Android 10.

malbry

Just to add: I am requesting

"account_info.read", "files.content.read", "files.content.write"

Greg-DB

I see, thanks, that's helpful. Yes, it looks like this is because this "JabpSync" app hasn't been migrated to use scopes yet, but this startOAuth2PKCE method does set scopes. Apologies for the generic error message though. I'll ask the team if we can get a better error returned in that case.

Anyway, to address this, you will need to migrate your app to scopes first (or use a different app key, for a scoped app, for development for now).

hubermichael

Thanks, this answers all my questions I had on integrating the new short-lived tokens. Btw. very easy to use Android-SDK implementation!