➡ Need volunteer to help fix node-red-node-dropbox

General
1

The popular node-red-node-dropbox has been around since 2015, and is still popular today.
However some months ago, Dropbox stopped issuing long lived tokens, and moved to an api using short lived tokens instead, which because the node has not been updated resulted in the tokens expiring after about 3hrs, rendering the node, and their flow inoperative. Also, if existing Dropbox users lose their current token, they will face the same problem.

The original author of the node no longer supports it, and it is currently hosted in the node-RED repo, so I am asking if anyone would be willing to take a look, and hopefully update the node to reflect the api change.
I have tried, but TBH, I don't possess the necessary skills, but I have been in contact with a very helpful dropbox techie, who has said;

There isn't some only correct answer to your question. It's matter either of every library' and/or application' design. The correct way depends primarily on how you prefer private info to be handled (any authentication info is a private info).
In your code you are instantiating the client object using access token only. As I mentioned before that's where your issue is coming from.
Take a look here on how actual refresh process appears (from initial authentication to refreshing steps at the end - internally as HTTPS transactions).
As you are using pre-generated credentials (as far as I can see), ordered HTTP calls can be used to get to all needed credential information, not just only access token.
Such information is not accessible through application console as was for long lived access token (not yet, at least). Once you get to all needed credentials, correct client object can be instantiated using correct Dropbox constructor's options (accessTokenExpiresAt, refreshToken, clientId, and clientSecret all in addition to accessToken). That's it.
Hope this casts some extra light.
Add: The only mandatory options to getting refresh process on are refreshToken and clientId, but depending on selected authentication clientSecret may be required too. Others can be useful to optimize the refreshing in some cases (save and reuse).

I have also had an offer of help;

Hi Paul
Thanks for bearing with us as we've been migrating to short-lived tokens!
One thing that might help, you mentioned you've made some attempts at updating your code to use short-lived tokens.
If you have a pull-request or some work done you can post here, we can take a look and might be able to provide more specific guidance.

Despite that kind offer (which is still very much open), again my skills would not present a serious submission, but I have no doubt that any node-RED contributor could accept this offer (I can provide contact details).

If nobody rises to the challenge, the node will probably be deprecated, which will be a loss to node-RED users, also there is no other contrib node that interacts with Dropbox.

Any volunteer?

2

Why not clone/fork the repo to your GitHub and ask the kind person to take a look. They may well PR against your repo?

3

They have already seen the repo, and the offer made is to look over the progress, and give us specific guidance.
Not to do the work for us!

I think that we need someone with Oath 2 knowledge to at least make a start, and then let the Dropbox techies advise us what we've got right/wrong.

1 Like
4

Hey Paul,

This is out of my capability range also i believe - but i did some digging and found this

which then leads onto this

Which appears to be a hint about the way to approach it in JS - but i have no idea how to take that and turn it in to a Node - i am also looking at n8n as they have a dropbox node and trying to work out if/how to get access to their code

Craig

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.