We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
Intermittent "code has expired", on authorization with .NET SDK
I have integrated Dropbox into a software running on a touch-screen kiosk type Win10 machine, using the provided .NET SDK.
Because a web browser is not available, the user has to generate a Dro...
Hi @giovaniluigi,
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.
It seems though more at issue is the exchange a code for a token. If I understand correctly, all codes must be transferred manually from the computer to your kiosk, and so it's possible your users are sometimes taking more than the five minutes these tokens are valid for. In addition, if they don't type it in exactly correctly then it won't work.
Your use case sounds like what the OAuth 2.0 Device Authorization Grant was designed for. However currently Dropbox does not offer this flow. I will however bring this up with our team to see if we can in the future.
Hmm, I meant that its not often that a big company update their server and break all existing code running on their own SDK
About the code to reproduce the behavior is really 1 line:
await DropboxOAuth2Helper.ProcessCodeFlowAsync(authorizationCode, appKey, appSecret);
That call will throw, complaining about authorization code expired, for a code that is not supposed to be expired (i.e. generated a few seconds earlier)
Now of course that its not for all users. It works 100% of the time for some users on different machines, while for others will fail like 2 times out of 3.
That obviously is not the most used authorization flow (manually entering the authorization code) so there is much less data about issues.
It is also more vulnerable to validation issues for many reasons, especially given the fact that the code is generated in one machine, then entered in another one. I wonder if this is part of the problem. Usually an authorization code is valid by itself and should not require additional security checks, like client name, IP, location...
Scott-DB
Dropbox Staff
Dropbox StaffHi @giovaniluigi,
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.
It seems though more at issue is the exchange a code for a token. If I understand correctly, all codes must be transferred manually from the computer to your kiosk, and so it's possible your users are sometimes taking more than the five minutes these tokens are valid for. In addition, if they don't type it in exactly correctly then it won't work.
Your use case sounds like what the OAuth 2.0 Device Authorization Grant was designed for. However currently Dropbox does not offer this flow. I will however bring this up with our team to see if we can in the future.
About Discuss Dropbox Developer & API
Make connections with other developers
