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
Questions about the usage limit of a refresh token (and access tokens)
I'm attempting to develop an application that uses the Dropbox API in python on the background (that means that the users won't know I'm using this api). The application is a control system framework...
Carl HR wrote:... So, I just need a single account to store the data (the application will handle the downloads and uploads on the background).
From the OAuth Guide, I've been able to generate my own refresh token, and store it inside the python's script, as a string.
...
Hi Carl HR,
It's never good idea to share any credentials to/between users! Embedding refresh token (or any other type of such information, like access token, password, etc) will expose the same access to all and possible privacy violation. That's why better use a way to store such information somehow and instead of let users "won't know" that you're using API, let them sign in their own accounts so the information will be stored secure with guaranteed privacy. Alternative can be such access to be provided by you with your own web service that serve as a proxy between users and your own Dropbox account, so you have control who can access what.
Carl HR wrote:...
In my current app version, I'm never storing any access tokens in the disk. Should I do it? I mean, should I store each access token in a file, so when the user opens a new instance of the application, it should attempt a connection using the Dropbox constructor with that loaded access token, and only use the refresh token if the access token has expired?
Or is it (morally) ok to use the refresh token every single time, and blindlessly allocate new access tokens at will (at every new instance of the application) even though they expire after 4 hours?...
Good point. You can do it as you like. Dropbox doesn't mandate you to store access token, so you can skip it - it's not strictly needed. Such a way is suitable for applications and services where once run they stay running for relatively long time. For short running applications, like command line tools, where the application' instance runs for just a single (or few) API call, you can think for optimization (no meaningless refresh for every regular API call, that can slow down the work). Again it's not something mandatory. You can take a look here for example of such a simple optimization. Of course, you can do it better
Dropbox SDKs don't support saving access token and, if you decide, have to implement it yourself as you like (as implemented in the referred example for instance).
Hope this helps.
Carl HR wrote:... So, I just need a single account to store the data (the application will handle the downloads and uploads on the background).
From the OAuth Guide, I've been able to generate my own refresh token, and store it inside the python's script, as a string.
...
Hi Carl HR,
It's never good idea to share any credentials to/between users! Embedding refresh token (or any other type of such information, like access token, password, etc) will expose the same access to all and possible privacy violation. That's why better use a way to store such information somehow and instead of let users "won't know" that you're using API, let them sign in their own accounts so the information will be stored secure with guaranteed privacy. Alternative can be such access to be provided by you with your own web service that serve as a proxy between users and your own Dropbox account, so you have control who can access what.
Carl HR wrote:...
In my current app version, I'm never storing any access tokens in the disk. Should I do it? I mean, should I store each access token in a file, so when the user opens a new instance of the application, it should attempt a connection using the Dropbox constructor with that loaded access token, and only use the refresh token if the access token has expired?
Or is it (morally) ok to use the refresh token every single time, and blindlessly allocate new access tokens at will (at every new instance of the application) even though they expire after 4 hours?...
Good point. You can do it as you like. Dropbox doesn't mandate you to store access token, so you can skip it - it's not strictly needed. Such a way is suitable for applications and services where once run they stay running for relatively long time. For short running applications, like command line tools, where the application' instance runs for just a single (or few) API call, you can think for optimization (no meaningless refresh for every regular API call, that can slow down the work). Again it's not something mandatory. You can take a look here for example of such a simple optimization. Of course, you can do it better
Dropbox SDKs don't support saving access token and, if you decide, have to implement it yourself as you like (as implemented in the referred example for instance).
Hope this helps.
About the question, that solves it I guess. I've been using the dropbox API for a few days so far. I didn't have time to read the docs properly to find the answer myself. Now, about your phrase: It's never good idea to share any credentials to/between users, you mean it for the danger of someone to use reverse engineering on my application and read those values?
Carl HR wrote:... Now, about your phrase: It's never good idea to share any credentials to/between users, you mean it for the danger of someone to use reverse engineering on my application and read those values?
Yes, of course, for instance. It's not so difficult Python script to be read, even when distributed as precompiled form.
By the way, it's not something Dropbox API specific. That's something to be considered in general coding!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
