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
Simple Node script not working with clientId /secret
I'm trying to do the worlds simplest node dropbox script but getting an error, clearly I am missing something. I set up an App - and gave it all the read permissions. Then I have this script ...
I was able to get this all to work as a script. So far it has worked great, running every 15 minutes for the last week. I only do the dropbox auth part if the thing I want to share has actually changed which happens several times per day during working hours.
In order get the refresh token chatGPT give me a script to run in powershell:
I pasted this in all at once:
$clientId = "yourAppIDHere"$clientSecret = "YourAppSecret"$authorizationCode = "ACCESSCodeFromPreviousStep"$base64Auth = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("${clientId}:${clientSecret}"))$headers = @{ Authorization = "Basic $base64Auth"}$body = @{ code = $authorizationCode grant_type = "authorization_code"}$response = Invoke-RestMethod -Uri "https://api.dropbox.com/oauth2/token" -Method Post -Headers $headers -Body $body# Output the access token$response.refresh_tokenThat gave me refresh token that I can then use to get a current access token - so that is hard coded in the script.I then have a db auth function which uses that refresh token and returns a new access token:import fetch from "node-fetch";const clientId = "yourAppID";const clientSecret = "YourAppSecret";const refreshToken ="RefreshTokenFromPowershell";// Function to refresh the access tokenexport default async function refreshAccessToken() {method: "POST",headers: {"Content-Type": "application/x-www-form-urlencoded",Authorization: `Basic ${Buffer.from(`${clientId}:${clientSecret}`).toString("base64")}`,},body: `grant_type=refresh_token&refresh_token=${refreshToken}`,});const data = await response.json();console.log("data in refresh :>> ", data);if (data.access_token) {return data.access_token;} else {throw new Error("Failed to refresh access token");}}Then I use that access token like you normally would.import fetch from "node-fetch";const config = {fetch,accessToken,clientId,clientSecret,};const dbx = new Dropbox(config);const data = await dbx.filesListFolder({ path: "" });
yes, first time trying to do anything with the dropbox api, and in general I am not the most skilled at this but can usually get the job done. I did look thru lots of example and have not seen anything like what I want to do (node script on schedule).
I can do what that code does with an access token, but that only works for a few hours thus why I tried to use the app id and secret.
All of the examples I have seen need to interact with someone via a browser or like that prompt to get a token - but this is just for a script that I want to run on my own files and it will run on a schedule so there won't be anyone around to fill in the prompt. It sounds like this used to be easy when the access codes were not short lived.
Can you tell me if the app id/secret can do this? I have seen other posts by you I think that said the app id/secret does not have access to any particular users DB but somewhere else I read that it should be able to do stuff with the apps folder.
I'll try to get the refresh token thing to work with an access token since I'm guessing I am misunderstanding the purpose of the app id/secret.
Thanks for the reply.
rdyar wrote:... since I'm guessing I am misunderstanding the purpose of the app id/secret.
...
Yes, for sure. As their name part (app - 'app' key/id and 'app' secret) suppose, it's not account related, but application related. To access particular account related thing (like listing some folder in Dropbox account, even when the account is yours) you need to authenticate the account, not application (even when the application is your property). Otherwise you don't have access to there.
rdyar wrote:...
I can do what that code does with an access token, but that only works for a few hours thus why I tried to use the app id and secret.
...
Yes, access token is short lived and works for limited time span (4 hours or so). As explained above already, app related authentication cannot replace account related! For long term access you need refresh token that doesn't expire automatic and can be reused. The common (border) thing between application authentication and account authentication is OAuth flow. To get refresh token, you need to perform offline access type OAuth flow.
Hope this sheds additional light.
so basically you can't just have a simple script run on a schedule (not an app that is running) and be able to access the users files without having some sort of interactivity to authenticate?
Even if I do the refresh token I'd still have to store it but my intention was to just have a simple script and handle the permissions/access by setting something in an env. Even if I did store the token somewhere my guess is eventually it would want to authenticate again and the script would break.
I have not seen any examples of this type of use case, the only mentions I have seen were people using the old long lived tokens seeming to come to the same conclusion more or less.
Здравко wrote:... For long term access you need refresh token that doesn't expire automatic and can be reused. ...
rdyar wrote:so basically you can't just have a simple script run on a schedule (not an app that is running) and be able to access the users files without having some sort of interactivity to authenticate?
...
Probably you haven't read my previous post carefully. 🤷
rdyar wrote:...
Even if I do the refresh token I'd still have to store it but my intention was to just have a simple script and handle the permissions/access by setting something in an env. ...
Hm..🤔 To be honest, I have no any idea what you mean here. Yes, you need to store the same as you do it for app id, app secret, etc. (including in env or somewhere else - wherever you want).
rdyar wrote:... Even if I did store the token somewhere my guess is eventually it would want to authenticate again and the script would break.
...
🙂 Again read my previous post more careful. Your assumption is wrong!
rdyar wrote:...
I have not seen any examples of this type of use case, ...
Yes, most of the examples are simplified. You can take a look here how you can perform OAuth flow in proper way and how you can use the received refresh token. In spite significantly simplified, the example may give you idea how you can get the things working (don't repeat the example one to one in your code - store the received token instead). Even more, you can perform the OAuth flow outside the application and only use the refresh token inside (similar to long lived access token - not the same!!!). You can see here how you can get to a refresh token by hands.
Good luck.
that last part sounds promising - OAuth outside the app.
When I do the second step in that post where you are using curl to "materialize the code" I get errors - saying that -u is ambiguous. If I change it to one of the suggestions then it complains that -d is used too many times:
curl https://api.dropbox.com/oauth2/token -d code=FBB9bkp9HG8AAAAAAAKA_rGNCro3U_3ivlcfb6vXrg -d grant_type=authorization_code -u 0y3gaiz5efo2sr:63fcehmajsdex(I edited the strings so that is not the real values).with -u I get:Invoke-WebRequest : Parameter cannot be processed because the parameter name 'u' is ambiguous. Possible matches include: -UseBasicParsing -Uri -UseDefaultCredentials -UserAgent.If I change -u I get:Invoke-WebRequest : Cannot bind parameter because parameter 'd' is specified more than once. To provide multiple values to parameters that can accept multiple values, use the array syntax.I'm on windows and haven't use curl but it seems like it should work now a days. But maybe it is windows related.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
