We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
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, and I'm just using the API to store global settings for all instances of the application (the goal here is to make this work between different computers, that's why it must be online). 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.
Every time I lauch a new instance of the application, it calls the Dropbox constructor:
import dropbox
appKey = ''
appSecret = ''
refreshToken = ''
dropbox.Dropbox(app_key=appKey, app_secret=appSecret, oauth2_refresh_token=refreshToken)
Now, my question is about the usage of the refresh token and its limitations, and possible guidelines of how to use it (if there are any rules I don't about).
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?
Finally, if the answer to the first question above is a yes (that is, it's not morally ok), is there a way to save the access tokens using the python sdk? Or should I do this mannually using the built-in file handling functions?
I understand my application won't have many users. It probably won't even apply for production, but I was still curious about this topic. I tried to research it in many sites and forums, and found nothing about it.
Thanks in advance.
Carl HR.
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.
