You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
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.
Thanks Здравко for your answer on that problem. I imagined the temporary revoke would be a problem related to the time limit mentioned in recent posts, but I thought the SDK would still work.
These are breaking changes... We don't see that often these days.
Now that still does not answer the issue while trying to exchange authorization code by token.
That one is currently my biggest issue.
I don't see how a server that issues an authorization code, would say that this same code has expired a few seconds after generating it.
To me that is non-sense. But that is what the SDK says on the exception.
giovaniluigi wrote:... I imagined the temporary revoke would be a problem related to the time limit mentioned in recent posts, but I thought the SDK would still work.
These are breaking changes... We don't see that often these days.
...
😯 Wow... If you have seen that is less than 100% after 4 hours... 🙂 You have discovered something like perpetuum-mobile. 😁 But while working for you it's Ok.
About the rest. 🤔 Some piece of code reproducing the issue (piece that can be compiled and run) would be a good start point. Let's hope there is somebody here able to direct you through once there is a example to evaluate.
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...
giovaniluigi wrote:Hmm, I meant that its not often that a big company update their server and break all existing code running on their own SDK
...
Hi giovaniluigi,
Might be said, but how would you improve something like long lived access token when it's considered insecure? 🧐 Actually all existing tokens work still, only new can't get issued. In such a way there is back compatibility.
You "code" is not something opaque that can securely reproduce the state. The statement is context sensitive! It depends on how you have launched your browser (your URL), for example. The set of required arguments can vary and their format too. Selected authentication flow is very important! That's why a single line of code (like your) isn't enough. Can you write a dummy program with this line and reproduce the issue? 🙂 That's what I'm asking for.
giovaniluigi wrote:...
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...
In general, there should not be a problem URL to be launched on different machine and then produced code returned back. This can't be a problem itself. The statement that "authorization code is valid by itself and should not require additional security checks" is definitely not true!!! That's exactly what your "code" is doing when launched - code verification together with all other passed arguments (let's imagine there is some required argument, but you don't pass it). 😉 And most probably this assumption is leading to such consequences. Be more careful... with the context.
If I create a console application and write that 1 line of code passing the provided argument that can be generated from the Dropbox console, it will generate the result I am saying. It will throw (sometimes... hence my problem).
Also, for the .NET SDK that one line call is for a static method in a Helper class, and should carry no context by convention. The context you are looking for is the SDK requests, the OS, the connection, network driver, IP, location... Exactly what I am looking for here, since I don't know what the server is looking during validation, and the Dropbox SDK provides a message that conveys doubtful information. Even if I trust the message and assume that the token is indeed expired after seconds of being generated, the question "why?" remains.
The idea to have the authorization code is to give trust to the owner of that authorization code. If you need to interrogate that owner, then you can't trust the owner to begin with. So that is my point. Possessing the code is enough for that purpose. And it is the only data that the Dropbox page provides you anyway. If different machines would not be a problem, as you said, that is basically saying: who presents me the code is trustworthy
Scott-DBDropbox Staff
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.
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
