Child Item

API Newbie: Authenticating and using on client side while keeping accessToken/App secret hidden

Hi, I am unable to figure out the flow to get clients who are logged in to my app to access Dropbox without creating a `const dbx = new Dropbox({accessToken:<MY PERMANENT ACCESS TOKEN THAT SHOULD BE HIDDEN>})` class. I can authenticate the server on the back end but then I don't want files to have to go via the server, when the client should be able to load and save documents from the client side.

Am I missing something in the documentation or am I just unaware of some basic Node.js knowledge that does allow me to create the class on the back end then pass the `dbx` class to be used on the client? I can't see that being a thing, somehow.

Alternatively, I imagine something like a fetch call to a dropbox endpoint with the client_id that then checks with my provided server endpoint for a valid accessToken or secret key and if verified returns to the client with one-time accessToken for use during that session?

Thanks for the guidance!

Find more posts tagged with

API

Abuse

Comments

Greg-DB

While you can plug in an access token for your own account like you showed here, the API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. That's accomplished by implementing the OAuth flow in your app, so that each user can authorize the app to access their own Dropbox account (such that the app receives a distinct access token for each user). You can find information on how this works in the OAuth Guide.

For the JavaScript SDK in particular, there's an example of doing this with a node server-side app here, as well as an example of doing this in a JavaScript client-side app here.

Alternatively, do mean that your end-users should only be interacting with the contents of your own one Dropbox account? That's not the intended/supported use of the API, but it is technically possible. You shouldn't expose your access token to the end-users client-side though, so in that case you may want to use filesGetTemporaryLink and filesGetTemporaryUploadLink instead. That is, you can make those calls using your access token on the server, and just pass down the links (but not the access token) to the client.

horton

Hi @Greg-DB ,

We already have a production-approved app that uses your API (openmusic.io). We are considering a change that would mean less friction for users. The change would involve using a single Dropbox account (eg. Advanced) and enabling users to take advantage of the storage and sync capabilities via the API. We would thereby cover the costs for our users. In a previous post, you said it is technically feasible but not supported.

My question is: if we build it (or adapt the current app for this purpose), do we need to reapply for production approval?

Greg-DB

@horton Apps already in production do not need to re-apply for production, but again I should highlight that this single-user pattern is not officially supported. In any case, production status is only needed for apps that need to have more than 50 accounts linked, so it wouldn't be technically needed in that case anyway.