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
"App Authentication" for App (without tokens). Yet another migration from long lived tokens question
Hi there! I see there have been a lot of questions in the forum on this topic, so I'll just cut to the chase.
My app is made in Meteor (NodeJS) and React. Clients of my app do not need to handle fi...
lalomores Just like with long-lived access tokens, the user needs to manually authorize the app once to get the refresh token, which can then be stored and re-used without further manual user interaction. In that example, you can see where the SDK returns the refresh token, which is then set on the client, on this line: https://github.com/dropbox/dropbox-sdk-js/blob/main/examples/javascript/simple-backend/code_flow_example.js#L38 . You can store and programmatically re-use that 'token.result.refresh_token' value similar to how you would store and programmatically re-use a long-lived access token.
The refresh token is used to programmatically retrieve new short-lived access tokens whenever needed, without the user necessarily present. Those new short-lived access tokens that get retrieved automatically are what are used to then make actual API calls, such as filesListFolder (or usersGetCurrentAccount, as in the example).
Anyway, while Dropbox and the Dropbox API aren't really designed to be used as a CDN, we do recommend using the official SDK(s) whenever possible for accessing the Dropbox API. And using the app folder access type whenever that works for the use case is also a best practice.
Thank you very much @serickson
Does the dropbox-sdk-js have a way to obtain the refresh token programmatically without prompting the user? As per your feedback I guess it does, but I'm just not hitting that nail it seems.
From the aforementioned example:
const config = {
fetch,
clientId: 'jg8wc1hfkvel6ql',
clientSecret: 'f0i5w4e6mlbbme5',
};
const { Dropbox } = require('dropbox'); // eslint-disable-line import/no-unresolved
const dbx = new Dropbox(config);
That way I initialize Dropbox in the server using clientId and clientSecret.
What's next in order to enable this.dbx.filesListFolder ?
I'm a bit tangled up looking and playing with the APIs at https://github.com/dropbox/dropbox-sdk-js/blob/main/src/auth.js
Also, given the context I've mentioned and my app objectives (basically, to use Dropbox as a kind CDN for my app's images), would you advise a better way to use the Dropbox SDK and App folder to achieve my goals?
Thanks a lot.
Greg-DB
Dropbox Staff
Dropbox Stafflalomores Just like with long-lived access tokens, the user needs to manually authorize the app once to get the refresh token, which can then be stored and re-used without further manual user interaction. In that example, you can see where the SDK returns the refresh token, which is then set on the client, on this line: https://github.com/dropbox/dropbox-sdk-js/blob/main/examples/javascript/simple-backend/code_flow_example.js#L38 . You can store and programmatically re-use that 'token.result.refresh_token' value similar to how you would store and programmatically re-use a long-lived access token.
The refresh token is used to programmatically retrieve new short-lived access tokens whenever needed, without the user necessarily present. Those new short-lived access tokens that get retrieved automatically are what are used to then make actual API calls, such as filesListFolder (or usersGetCurrentAccount, as in the example).
Anyway, while Dropbox and the Dropbox API aren't really designed to be used as a CDN, we do recommend using the official SDK(s) whenever possible for accessing the Dropbox API. And using the app folder access type whenever that works for the use case is also a best practice.
Oh, I see. I finally understand. Thank you Greg and everybody for your patience.
So, in short, what I want is not possible:
1. It is not enough with the client Id and client Secret to programmatically obtain a refresh token.
2. I can't avoid having to go through at least one oauth flow in the client to retrieve a refresh token.
If I want to entirely hide the Dropbox oauth flow from my users, I need to do it in a kind-of-hacky way: run it myself either in my app or in an example code as the aforementioned, capturing the generated refresh-token in the server and then using it as a constant for my app's initial setup. Is that right?
I think my confusion came from the fact that it didn't quite feel like I was authorizing anything when I generated a long-lived token in the app panel. The same way it didn't feel like I was authorizing the client id and secret when I created the app in the console. It felt more like configuring/setting up.
So, to give closure to this matter and if you would be so kind to answer me one more time: Would you say obtaining a refresh token, capturing it and using it as a long-lived token is something that goes against Dropbox's intended/best practices?
Otherwise, if Dropbox is actually expecting refresh tokens to be used as long-lived ones, an idea that comes to mind is maybe replacing the "Generate access token" with a "Generate refresh token" in the app console, as this section feels more like configuration than temporary data. And maybe leaving the "Generate access token" (and maybe calling it: Generate short-lived access token) in the API explorer, so it is clear it can be used for a little while just for testing purpose.
Thanks a lot for your insights and help.
Best regards
- Greg-DB
Yes, that's correct. The API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. While it is technically possible to always connect to just one account for all users, we do not officially support this, for various technical and security reasons.
I'll also pass this along as a request for a "Generate refresh token" option, as well as to clarify the token lifetime in the API v2 Explorer, but I can't promise if or when that might be implemented.
+1 for "Generate refresh token"
Hello,
It seems that it is not true that the RefreshToken have permanent duration.
I got a Refresh Token by calling from my browser the url https://www.dropbox.com/oauth2/authorize?client_id=xxxxxxx&response_type=code
Then i used postman to get a short-lived access token using a POST call to the url https://api.dropboxapi.com/oauth2/token using the requered paramethers (Refresh token included)
After the short-lived access token finishes his useful life (4 hours) i ran again the same Postman Call (with the same parameters) to get a new short-lived access token, but now the response is
{"error": "invalid_grant","error_description": "code doesn't exist or has expired"}Can you helpme please to solve tis issue?... i spent many hour trying to automate mi process but still i can't.Hi maxcastrovidal,
Don't have any doubts - refresh token doesn't expire by itself.
maxcastrovidal wrote:...
After the short-lived access token finishes his useful life (4 hours) i ran again the same Postman Call (with the same parameters) to get a new short-lived access token, but now the response is
{"error": "invalid_grant","error_description": "code doesn't exist or has expired"}...👍Yes you are on the right track, you need to refresh (to create anew) your short-lived access token from the refresh token you already have. But... 🤔 Why are you using already expired code used formerly to get to the refresh token???! Once again, you already have this refresh token! Even more, code used to get this token is "single shoot" (i.e. once used, you can't use it any more and don't need actually).
Don't try to "refresh" refresh token itself, if you are trying this! You need to refresh the access token! Access token refreshing doesn't need "code", but a refresh token instead. 😉 Check what granting type you have selected (may be a copy/paste error - grant types for refresh token and access token are different).
Hope this helps.
By the way, using:
maxcastrovidal wrote:...
I got a Refresh Token by calling from my browser the url https://www.dropbox.com/oauth2/authorize?client_id=xxxxxxx&response_type=code
...... you will never get any refresh token!!! You have to specify explicitly offline access! Something like:
https://www.dropbox.com/oauth2/authorize?token_access_type=offline&response_type=code&client_id=<App key>In your situation whatever you are counting as a refresh token, it's not! 🤷
- Greg-DB
maxcastrovidal Здравко is correct; in short, it sounds like you're attempting to use the "authorization code" more than once. The authorization code can only be used once. Once you get the refresh token, you should store and re-use that, not the authorization code, to get new short-lived access tokens whenever needed, via /oauth2/token with grant_type=refresh_token.
About Discuss Dropbox Developer & API
Make connections with other developers
