We introduced in version 2.0.0 of the dropbox node the concept of refresh tokens, to allow this node to support the new stronger Dropbox security guidelines.
However our mechanism was based on OAauth2 redirect url's, which required the connection between Node-RED and the flow editor to be SSL with certificates signed by a trusted CA (e.g. LetsEncrypt). Normally it is bad practice to use plain HTTP, however when everything (flow editor, Node-RED, ...) is located in a secure LAN behind a firewall this should be possible.
Therefore I have completely refactored the code, and now the Oauth2 related code is completely moved to the frontend part of the Dropbox node. Now it allows both HTTP and HTTPS connections.
*CAUTION: it is highly disadvised to use plain HTTP outside your LAN!! And even within your LAN it is better to use HTTPS.
But of course that is a general guideline, and is not specific for this node. So I would like to not discuss that further here, and keep this discussion focussed on the Dropbox node...
The below diagram shows an overview of the entire refresh token request flow:
I think this diagram should be added to the readme page of the dropbox node. Unlike in the previous version were my diagram explained the technical flow between the endpoints, this new diagram only explains which screens the user will get to see.
Such diagrams help me to see where I the process I am situated. Like e.g. when I am configuring my Google home node, I always get lost in what I am doing at the moment. Or whether it is normal if I see some screen at some time within the process....
Thanks for testing!
It is in my Github repository under the "dropbox-refresh-token-refactored" branch.
So I think that between the cd and npm install you need to do git checkout dropbox-refresh-token-refactored. That way git will get the files from that branch and store it in your directory...
Thanks for testing!!
I assume you have tested only via https to Node-RED?
Will have a look tonight whether I can change that button label. Never had a look at it. Thought it was always looking the same for all nodes...
Did you just try it once and got the error, or did you get it after several attempts?
I've had that same error (with the previous Dropbox version) after I had made a silly mistake in entering the credentials (my fault!). I tried a few times, then got the 'user limit' message.
I left it a few hours, corrected my error, and then everything worked OK.
Full log from npm install ~/node-red-web-nodes/dropbox
pi@PiVPN:~/.node-red $ npm install ~/node-red-web-nodes/dropbox
npm WARN firstname.lastname@example.org requires a peer of @types/node-fetch@^2.5.7 but none is installed. You must install peer dependencies yourself.
npm ERR! code ENOENT
npm ERR! syscall rename
npm ERR! path /home/pi/.node-red/node_modules/.staging/node-red-node-dropbox-83c3ac53/node_modules/balanced-match
npm ERR! dest /home/pi/.node-red/node_modules/.staging/balanced-match-cab3dc10
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, rename '/home/pi/.node-red/node_modules/.staging/node-red-node-dropbox-83c3ac53/node_modules/balanced-match' -> '/home/pi/.node-red/node_modules/.staging/balanced-match-cab3dc10'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent
npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2023-01-07T20_41_40_043Z-debug.log
I had a similar issue last week when I used the dropbox app from @Paul-Reed to test. But then I switched to my own app and the issue hasn't occured anymore.
I am not using Dropbox myself so I am not a specialist. But read this somewhere: If you have created your own Dropbox app, you can only connect to it from one domain and for 1 Dropbox account. However you can increase the number of accounts/domains without applying for production by clicking on 'Enable additional users' in the App Console (Login - Dropbox).
I suspect this was my problem: Paul had accessed his test dropbox account via domain A (e.g. https;//domain.from.paul) and I wanted to access the same dropbox account via domain B (e.g. https://domain.from.bart). Which seems not to be allowed. Did you do anything similar in your test?
The setting looks like this in my own Dropbox account, so I assume I can also use it only via one domain:
I assume it now occurs for you because here it seems that the dropbox SDK uses node-fetch to refresh the access token (based on your refresh token).
But I don't use npm enough to troubleshoot this. Hopefully somebody else can give some tips...
Should I perhaps add the node-fetch library as a dependency to the dropbox node?
Here you can find the official documentation. So it seems indeed - while your app is still in development mode- you can allow more clients to access your app, via that setting in your Dropbox account. I haven't tested it!