We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Short lived token - Android user experience
What should the user experience be like for someone using my Android app after migration to short-lived access tokens? Currently we save a long-lived token in persistent storage for the app, so the user normally only authenticates once for the life of the app. It seems that the user authentication happens either in Dropbox app (if the user has installed it on their mobile device) or in a browser (if the user has not installed the Dropbox app.) In either case, the user has to enter an ID and a password the first time. Thereafter, the user is only shown a prompt to accept or reject the authentication request, but no more need to enter the Dropbox ID and password. This happens with either the Dropbox app authentication or the browser authentication. Do I have that right?
So after migration, new users will do the same thing, but my app will get a short lived token. I gather there is no reason for me to store this token beyond that one session anymore since it will have expired by the next day at least. Therefore my app should behave the same the next session, by initiating an authentication request that requires user interaction (but no passwords) at every session. Do I have that right too?
Finally, suppose I made the mistake of trying to use a short term token after it had expired. For example, when I want to upload files from the mobile device to my App Folder in Dropbox, the first API call I make is:
DBXfer.sDbxClient.files().listFolder(dir);
inside a try block, and one of the exceptions I check in the "catch" block is
InvalidAccessTokenException
Is that what will happen if I use the short lived token after it expires?
Your description of the current (long-lived) implementation looks correct. The exceptions are if the user or app unlinks the app or revokes the token, in which case the user would need to re-authorize the app, and in that case, if they've since signed out of the app/web site, they'd need to sign in again to do so.
For the new (short-lived) implementation though, as long as you use the official Dropbox Java SDK as provided, you can get effectively the same behavior (from the user's perspective) as the long-lived implementation. To do so, you would start the authorization flow using startOAuth2PKCE (instead of startOAuth2Authentication) as shown here, and handle the result as shown here. When you do so, the credential will include both a short-lived access token as well as a refresh token, and the SDK will automatically handle expired short-lived access tokens for you by performing the refresh in the background.
- Greg-DB
Dropbox Staff
Your description of the current (long-lived) implementation looks correct. The exceptions are if the user or app unlinks the app or revokes the token, in which case the user would need to re-authorize the app, and in that case, if they've since signed out of the app/web site, they'd need to sign in again to do so.
For the new (short-lived) implementation though, as long as you use the official Dropbox Java SDK as provided, you can get effectively the same behavior (from the user's perspective) as the long-lived implementation. To do so, you would start the authorization flow using startOAuth2PKCE (instead of startOAuth2Authentication) as shown here, and handle the result as shown here. When you do so, the credential will include both a short-lived access token as well as a refresh token, and the SDK will automatically handle expired short-lived access tokens for you by performing the refresh in the background.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
