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.
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
Dropbox Staff
Dropbox StaffYes, 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"
Thanks a lot.
I have spent hours trying to get the API working. It worked great before the tokens started expiring every 4 hours. I have read everything I can find about this, but I can't piece it together. I have an app that need to access a dedicated Dropbox folder. I don't care who is using the app, and I don't want the users to need to authenticate. It worked well with the long term token I generated in the app console before that option was removed.
It seems like now I have to figure out how to build a separate app just to authorize and create the token. I would love to be able to generate a token from the app console similar to how we could before. This would save me many, many hours of work.
Hi dwissing,
Take a look on https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Issue-in-generating-access-token/td-p/592667 how you would be able do the same in regular terminal. 😉
Hope this helps.
So this shows how to refresh a token manually in terminal. My app is Vue.js. Current code is: import { Dropbox } from 'dropbox'
import { Dropbox } from 'dropbox' import axios from 'axios' async function get_thumbnail() { const dropbox_token = 'sl.**CODE**' const options = { format: 'jpeg', mode: 'strict', path: found_file_path.value, size: 'w64h64' } var dbx = new Dropbox({ accessToken: dropbox_token }) try { const response = await dbx.filesGetThumbnail(options) return response } catch (error) { console.log(error) } }
I can use the info you provided in a terminal to get a new access token, but how do I do it automatically?
About Discuss Dropbox Developer & API
Make connections with other developers
