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.
Hi Scott-DB, hmm you really provided one critical piece of information there.
So the auth code is only good for 5 minutes. Now it starts to make sense.
I believe that this time window has not always been respected. So that is very likely the cause.
As you know, the manual code is pretty long... so it makes sense that 5 min is probably right on the edge...Yes, the Device Grant would be the best option for us.
To make easier for our end-user, I am implementing a similar idea where the kiosk device polls our own servers...
IOT devices and small touch panels would benefit a lot from it.
About Discuss Dropbox Developer & API
Make connections with other developers
