Short lived tokens - node-RED community help needed

---

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).