Child Item

Using dropbox API from a scheduled Task: authenticating but NOT as a User

I need a job that moves 4 times a day files from a folder to dropbox and reading other files from another folder . Designin the architecture is not a problem. However I'm stuck with the API of dropbox. development done from mulesoft.

Authentication types - Developers - Dropbox

I see two main authentication types:
1) Oauth => it requires user to manually log in each time from a web form: requires manual interaction and a web service

2) App authentication => nice basic authentication, easy peasy.... or not. Because https://api.dropboxapi.com/2/files/list_folder

returns

{

"error_summary": "path/unsupported_content_type/",

"error": {

".tag": "path",

"path": {

".tag": "unsupported_content_type"

}

and searching for errors the problem is I cannot use the "path" because app authentication do not allow that.

Solved: When trying to list folder contents, error happens - Dropbox Community (dropboxforum.com)

So is there any authentication method that allows me to setup a "fire and forget forever" scheduled job? I need to move files and display them, my app is already configured correctly.

I tried to use of official Mulesoft Dropbox User Connector... It works to a certain degree. From what I understand there must be an additional authentication method not documented, because the connector is able to list the files.. given only the basic credentials.. however I cannot use the official mulesoft dropbox connector because it miss the

2/files/list_folder/continue

So basically I'm locked out of my task becase either:
1) there is not a authentication that works without user interaction that allows to access basic functionality (think it as a Backend to Backend requirment)

2) the piece of software that would allow such communication happen (using maybe a undocumented authentication feature?) has missing functionalities

AND the grant_type "client_credentials" is not working:

{

"error": "The server has either erred or is incapable of performing the requested operation."

}

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

@DarioO If you only needed to list the contents of a folder by using a shared link to that folder, you could use /2/files/list_folder and /2/files/list_folder/continue with app authentication. That would involve sending an app key and secret on both calls, and the shared link in the "shared_link" parameter on the /2/files/list_folder call.

If you need to be able to move files in the account though, e.g., using /2/files/move_v2 or /2/files/move_batch_v2, you do need an access token for that account (instead of just the app key/secret), as that requires user authentication.

In order to get an access token for an account, you do need to process the app authorization flow for that account at least once. As Здравко mentioned though, you only need to do that once if you request "offline" access. Doing so would give you a refresh token, which doesn't expire, and which can be used programmatically and repeatedly, without the user manually re-authorizing the app each time, to get a new access token whenever needed. The new access tokens can then be used to perform more folder listing and move calls.

For more information on using this authorization functionality, refer to the following resources:

All comments

Здравко

@DarioO wrote:
...
1) Oauth => it requires user to manually log in each time from a web form: requires manual interaction and a web service
...

Hi @DarioO,

You have a lot of misunderstandings how Dropbox API and OAuth work, but the above, that I underlined, is most important, I think.

In general No - you don't need log in each time if you have unexpiring token - refresh token. Access token expires and most probably you're taking into account only that part. If you authorize your access as offline type (i.e. you receive refresh token in addition to access token), you can refresh your access token using the available refresh token without additional user interaction. An simplistic example can be seen here.

Hope this helps.

DarioO

That's exactly what I would prefer to avoid. If something wrong I need to get another "code" from user Login and put it on back again. I guess that's would never be possibile, and anyway the mulesoft connector is working with Basic credentials, how does that works?

Greg-DB

For more information on using this authorization functionality, refer to the following resources: