How Can I Implement a Method to Refresh a Dropbox Access Token Using Pipedream URLs?

This topic was automatically generated from Slack. You can find the original thread here.

Greetings,

I’m wondering if anyone knows if there’s a way to implement a method using the Pipedream url’s that would enable a Dropbox access token to be refreshed.
I would execute a Pipedream url, that would then using axios send an OAuth token request to Dropbox and then capture the refresh token on the redirect url. I’ve been successful only in getting the html file on the return that requires a user intervention to retrieve and use the authorization code.
Dropbox’s access tokens are short lived and need to be refreshed. I’ve been having a difficult experience with these OAuth routines.
Since Pipedream does all of this OAuth stuff in the background, which is truly convenient, I’m needing a way to update the access tokens so that when they expire, I can quickly refresh the token.
They don’t appear to work very well unless you’re running an html file to accept the redirect. The challenge is, that I’m running my Dropbox api’s within a web worker, and don’t have direct access to the html of the app. When the access token for the Dropbox app expires, it requires a direct user intervention in order to obtain an authorization code, which then needs to be copied and pasted into the api to continue running. Pipedream seems to have resolved this problem, and I was wondering if these methods for updating an access token might be available.
In fact, it really wouldn’t be necessary to perform any type of routine on my end in the web worker, if I could just make an api call via Pipedream, and allow Pipedream/Dropbox api connection to provide the access token for my Dropbox app. A Pipedream trigger url might be able to act as the redirect_uri, that way everything would be able remain secure via Pipedream, and simply return the access token which is short lived, for about 4 hours.
Thanks,
Scott.

I think you can ask our bot to help write a code step for you

It seems like your message was cut off before you could finish your question about writing a code step. Could you please provide more details on what you need help with? Are you looking for assistance with writing a specific function or integrating with a particular service? Any additional information you can provide will help me give you the most accurate guidance.

are you using the integrated Dropbox app? And are you saying that your access token is expiring? We should be automatically handling the refresh for you, so if that isn’t working, then there could be a bug. Happy to investigate if you’re able to provide more info.

I think I have discovered the solution. In fact, it was right in front of me.
I have been using Pipedream to access the Dropbox api’s and once I selected the account, everything worked fine.
Now, I have developed a method that most of my Dropbox API’s can be performed within a web worker. As I was testing these procedures within the web worker, I kept getting expired access token because I learned that these are short lived, and they start with an sl.xxxxxxx string.
Apparently Pipedream simply generates a new Dropbox Access token when the account is selected, because when I did a console.log on the auths.dropbox.oauth_access_token, low and behold, it started with an sl.xxxxxx string.
So I created a small Pipedream work flow where I called users/get_account, and return the auths.dropbox.oauth_access_token.
Then I was able to use that token until it expired, and repeated the process, so that now I can always have an updated access token for all of the Dropbox api calls, and didn’t have to go through the OAuth learning curve/experience.
Kudos to Pipedream again!!!
Sorry to have bothered you with this issue.
Thanks,
Scott.

Oh got it, so you’re just using Pipedream to handle the access token refresh logic, and you’re running your code elsewhere?

Yes, and it seems to be working on MOST of the api calls. I have found there are a few call like files/get_temporary_link that at this point I haven’t been able to get to work. But that’s only a minor set back within my code. When I need to use that api call I will simply use the Pipedream workflow to either use it there, or return the tempLInk.

Update for any that are interested or who may run into the same problems I have.

I was finally able to get the Dropbox api call work within my web worker, but the following day, everything broke. Couldn’t get the access token to update the way that it did the day before, and it took me all day then next day until I discovered that I wasn’t converting the curl formats properly into the javascript format.

I was able to discover a conversion tool, here’s the link,

I placed the curl statement in the area for it, and it immediately converted the statement into an appropriate javascript fetch statement. I copied to code directly into the my program, added the access token in the appropriate place, and it worked perfectly.

Here’s the routine that I developed if anyone is interested.

Step 1. Listen for a file to be entered into a specific folder in my Dropbox account using the longpoll api.
Step 2. When a file gets moved into the folder, I separate the file types, mainly image files and receipt image files.
Step 3. The process can handle 1000s of files, but it only process about 20 at time because of both time and memory constraints within Pipedream. But that still reduces the number of invocations that are charged.
Step 4. I resize all of the image files that are over a certain size using require(‘resize-img’), in order to create thumbnail images in order to better view them within my html file.
Note: prior to resizing the image file, I implement EXIF = require(‘exif’).ExifImage, in order to obtain the original crreation date of the photo, and the orientation. That way, the program can rename the thumbnail image starting with the actual creation date of the photo. Yes, yes, I know, most of the image files name the file based on the date. However, it doesn’t provide you with the orientation and the width and height, which I get from the EXIF data.
Step 5. If the image file is a receipt, either from a photo, or a scanner, I use the awsTextract and after several weeks of the routines to analyze the types of receipts, I’m able to create name of the image file by the receipt date, and the vendor name, and it provides all the data for totals that will automatically load into the transactions areas of my app. Along with other utilities I can automatically load the receipts into their appropriate owner’s folder, with the vendors and owners name on the name of the thumbnail image file.

All my subscribers have to do at this point is place all of the files for projects into this single Dropbox folder. What makes this really cool, is that at the time of loading my app, they create a folder just for my app and share it with the app. That way all of the data and files that are processed using my app are actually doing all of the processing within their own Dropbox folder. If they don’t like the service, they can cancel at any time just by removing the shared status of that folder.

So you can see that this whole process of getting the Dropbox and Pipedream functions to work was critical for the operation of the app.

I hope there’s a few tidbits of information you might find helpful in developing your apps.
Scott.

have a look at the docs