We’re Still Here to Help (Even Over the Holidays!) - find out more here.
Forum Discussion
Short lived tokens - node-RED community help needed
The node-RED community, which numbers in excess of 30,000 members worldwide have enjoyed using Dropbox via a community contributed node for the past 5 years - https://github.com/Paul-Reed/node-red-we...
Hi Paul R.17,
Take a look on a simplified example here. You can get idea out from there, I believe. In short, new refresh token has to be added so your application can access desired account long term without additional user interaction. By now you are relying to short lived access token only and that's where your issue is coming from. 😉 That's it.
Hope this helps.
Thanks for replying.
I have already looked at that, but could not understand how/where it would be added to the existing code.
Unfortunately, most of us in the node-RED community are at a lower technical level, and are struggling.
Paul R.17 wrote:...
I have already looked at that, but could not understand how/where it would be added to the existing code.
...
Hi again Paul R.17,
🙂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 pregenerated 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).
Scott-DBDropbox Staff
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.
Thanks for the kind offer Scott-DB
However, not quite at that stage yet, but probably (very likely!) I'll take you up on that offer.
Meanwhile, most of the example SDK's relate to browser based apps. Is there a javascript SDK/example that is suitable for back-end applications that I could use to obtain the token?
Здравко I tried your demo link to create a token which worked fine, and produced a valid (short life) token which enabled the node-RED node to work OK.
But could you clarify this link which you posted earlier as it appears to be an example for use with browser apps, and not for a back-end app which run without user intervention. Is this the correct example for me to follow?
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
