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
How to migrate to new Auth workflow with python SDK while minimizing need for single user input?
Hello Dropbox team,
I have set up a small app as a python script which runs continuously on my server, and which needs to read some files that I store on my Dropbox storage space, in the folder...
FrancoisNOYEZ Здравко is correct, under the new system you do not need to interact with your script every time it runs. You can supply it the refresh token like you previously supplied it a long-lived access token and it will automatically run without manual user interaction, as before.
You do need to process the app authorization flow one time to get a refresh token though. You can refer to this example to see how to process the app authorization flow to get a refresh token, at which point you can then set up a client using it, as shown at the end of the example.
Greg-DB
Dropbox Staff
Dropbox StaffFrancoisNOYEZ Здравко is correct, under the new system you do not need to interact with your script every time it runs. You can supply it the refresh token like you previously supplied it a long-lived access token and it will automatically run without manual user interaction, as before.
You do need to process the app authorization flow one time to get a refresh token though. You can refer to this example to see how to process the app authorization flow to get a refresh token, at which point you can then set up a client using it, as shown at the end of the example.
Hello @Здравко, @Greg-DB,
Thank you for your answers.
Following your indications, as well as the example described in the examples scripts, I was able to define a "refresh token", and I indeed see that I only need to supply it, along with the APP_KEY and APP_SECRET, when instantiating a Dropbox class object. As long as I keep the 'oauth2_access_token_expiration' parameter equal to none, when carrying out this instantiation, I guess I will never need to perform new authentication operations, is that right?
With this new authentication scheme, we went from having to just specify a single token, to having to specify the APP_KEY, APP_SECRET, and refresh token. In terms of management of this sensitive authentication data, in your opinion, how should I proceed? I used to pass along the authentication token as a parameter to the command used to launch my script ('cause I don't want to write it down in my script). Is it ok to do something similar now (the difference being that I'll have to provide 3 values instead of one)? Seems like, as long as I keep those authentication -needed data in the same spot, nothing much was gained in terms of security (though now the scope associated to the token is read-only, so that seems like an improvement here). How could I improve the way I manage those data, if possible, in your opinion?
FrancoisNOYEZ wrote:
... As long as I keep the 'oauth2_access_token_expiration' parameter equal to none, when carrying out this instantiation, I guess I will never need to perform new authentication operations, is that right?
...Hi FrancoisNOYEZ,
In the practice, yes, most probably. If we should be more general, there are situations where refresh token could be revoked (both explicitly, by your or another person having access to the account, or implicitly, by some actions, which shouldn't happen in normal case). Even very unlikely, it's good practice to expect such a situation in your code (script or other). When something goes wrong and the token gets revoked, somehow, just inform/warn in suitable way, at least. The same is valid for long lived access token, used by you till now. 😉 Just a good practice that can make your life easy sometimes!
FrancoisNOYEZ wrote:
... In terms of management of this sensitive authentication data, in your opinion, how should I proceed? I used to pass along the authentication token as a parameter to the command used to launch my script ('cause I don't want to write it down in my script). Is it ok to do something similar now (the difference being that I'll have to provide 3 values instead of one)? ...🙄🙂😁FrancoisNOYEZ, If you care for data (of any kind) and don't want other process (and people accordingly) to touch it, command line is the worst place to pass such data (or not the best, definitelly, at least)! Command name a all options and parameters are object of logging in the shell history, at least. The same information is accessible through system tool for process monitoring (how exactly depends on exact OS in use, but accessible). Other ways are also possible! What think that you are hiding in such a way?!!! Be careful!
If I'm in your shoes, will look around your system and usually there is some sort of system "wallet". That's exactly what this service is dedicated for! Exact form is OS dependent, but generally there is some encrypted, system controlled storage where every application could reserve some space. There you can store sensitive data of your choice (like discussing here). The access is system controlled and one application can't touch data of other one and also the same application running on different account is restricted (there are different storage places). 😉 The just mentioned would be my choice.
The needed data representation can be stored on and received from a secure place (like the wallet above). On start, when available, could be used directly to instantiate Dropbox client object. When missing OAuth flow could run and result received will be used both for client instantiation and storage of sensitive data.
Hope this gives useful directions.
PS: For a almost platform independent way in Python try the "keyring" package. 😉 It behaves as a interface to corresponding installed system service. Or tries to, at least, and succeeds when there is available proper backend. Linux, Mac, and Windows are generally supported.
Hello Здравко
Thank you for your insights.
Ok, so barring voluntary revocation by someone, or some actions taken by DropBox, the refresh token should be valid indefinitely. At the very least, with it and the way I created it, I should be able to use it with the same level of 'no action' that I currently have with the use of the 'overall' access token.
I agree that it would be better if my app was able to react properly to the token being revoked or becoming non-functional; I'll see what I can do about that in the future.Well, I never said it was secure, I just said that I did not want to hardcode the access variables in the program (since I use control version, notably). Though, arguably, from what you are describing, using the command line to pass the secret seems like it's actually worse than hardcoding it in the program. I asked the question because I wanted to finally take the time to do something better with that respect : )
Thank you for the suggestion, I'll look into that, notably this 'keyring' package that you mentioned.I have been struggling with getting a refresh token and I was able to run your example successfully so that is great thank you!! But what I am still struggling with are two things: 1) How do I get the refresh token out of this and 2) how do I use it in my python code to actually log into dropbox and automatically use a file. For example with a regular token I use the below code, but the problem with the regular token is that it keeps expiring. So what do I replace this code with???:
dbx = dropbox.Dropbox(access_token)
with open(local_file_path, 'rb') as f:
dbx.files_upload(f.read(), dropbox_path, mode=dropbox.files.WriteMode.overwrite)
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
