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.
giovaniluigi wrote:...
Sometimes, after successful authentication the token seems to get revoked by the server after a while.
...
Hi giovaniluigi,
You should take in mind that all new access tokens are short lived access tokens (you can distinguish them with starting "sl."). Despite an existing long lived access token can still be used (if you kept any), new cannot be issued anymore (they are deprecated some time ago and issuing dropped already). If you want processing within your application, without user disturb for re-authentication, refresh token should be used. The refresh token doesn't expire itself (till explicit revoke). You are constructing your Dropbox client object using access token alone (with the constructor here)! That's where your issue is coming from - access token can alive for 4 hours, at most. Use another constructor (suitable in your case) that relies on refresh token instead. 😉
Good luck.
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.
About Discuss Dropbox Developer & API
Make connections with other developers
