Child Item

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-web-nodes/tree/master/dropbox

But now since introducing short lived tokens the app no longer works, breaking users flows, and forcing node-RED users to look at other storage options.

Having read the documentation & seen the examples, we find it overly complicated to implement, and a number of people have tried to update the code to refresh the tokens, but we've repeatedly failed!! (the nodes are community developed & maintained).

Has anyone successfully achieved the transition in a node.js environment, or can help us to update pls.

Find more posts tagged with

API

Abuse

Comments

Здравко

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.

Paul R.17

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-DB

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.

Paul R.17

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?

Paul R.17

@Здравко 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?

Здравко

@Paul R.17 wrote:
@Здравко 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.
...

Hi @Paul R.17,

Not only short lived token, but all needed to use refresh process.

@Paul R.17 wrote:
...
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?

I have no idea how you can run the pointed code in browser! 🤔 Did you try? 🧐 To be honest, I can't. Share your experience how you did it. That code is a simple backend application actually. Of course, you can see the application output in a browser, but the application doesn't run in the browser (as far as I know). 😉

Hope this cast additional light.

Paul R.17

@Здравко wrote:
I have no idea how you can run the pointed code in browser! 🤔 Did you try? 🧐 To be honest, I can't. Share your experience how you did it. That code is a simple backend application actually. Of course, you can see the application output in a browser, but the application doesn't run in the browser (as far as I know). 😉.

Sorry, I wasn't clear. Yes, I have tried, but it appears that I run the code, and then I open a browser to `localhost:3000` which then redirects to 2 consecutive pages to authorize access to my app, is there anyway to avoid this authorisation process?

Здравко

@Paul R.17 wrote:
... Yes, I have tried, but it appears that I run the code, and then I open a browser to `localhost:3000` which then redirects to 2 consecutive pages to authorize access to my app, is there anyway to avoid this authorisation process?
...

If you mean to avoid it completely - No (not yet, at least). If you mean embed pre-generated authorization info (like long lived token before) - Yes - that's why I pointed to procedure where you had seen generated short lived access token only, but there are all needed components, including refresh token. Using pre-generated authorization info, you will not need to process authorization within the application, if that's what you are asking for. Remove authorization code from your application and put there (on its out) already generated information (ready for use). Before (at time of long lived token) was the same choice pre-generated token or authorization within the application, so nothing new. The only limitation now (something probably confusing your) is missing single button for getting such information, as was before (that's why you cannot avoid it completely yet - this might change in future, but better don't rely). 😉 That's it.