Child Item

Multiple users interacting with one Dropbox account via the API

Hi!

I'm building a JS web app that requires end-users that are logged into the app, to interact with one Dropbox account via the API. The interaction is based on new files being created when a when a form is submitted, triggering an API call and using information from the form.

However I'm unsure how to go about the auth process that requires multiple people on different computers to interact with one Dropbox account after I read in another post on the forum, 'do you 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'.

So I assume that what I'm trying to do is possible but not advised? Could anyone shed a light on how it is technically possible or some alternative routes please.

Just to add, the account is a Business account that has assigned users...perhaps this opens up some other opportunities to achieve what I want to do?

Thanks

Find more posts tagged with

API

Abuse

Comments

Здравко

@oatcake wrote:
...
So I assume that what I'm trying to do is possible but not advised?...

Hi @oatcake,

You haven't mentioned, your application is server side one or user side. Server side application doesn't provide to users any sensitive information you don't provide explicitly. It's much more complex for client side application! To be able connect to Dropbox account, client needs particular authentication information. Once you provide your account information to a client, how are you planning to protect against undesired access? 🤔 It's a difficult task (a security management task)!!! Are you still thinking to use single account on client side application? Think again!

Hope this clarifies possible issues.

oatcake

It's a client side app built using React.

'how are you planning to protect against undesired access?'...by using the Dropbox SDK to handle authentication? I've been able to implement the auth flow for one end-user and assumed that would work the same way for other end-users using the web app but when I read that the API is not designed to be used that way I thought I better ask for some advice.

Thanks for the reply!

Здравко

Probably I'm not clear enough...

Yes Dropbox API uses secure connection and, Yes, data transfer is protected. That's not a possible issue. To be initiated any transfer (secure or not, doesn't matter) authentication token is need to provide access to your account in client browser. It's impossible a client to get access to your account without token! Probably that's what you are missing..., be careful. What will prevent a person to fetch this token and use it in arbitrary context, so can steal data, damage it, or heart in other way your privacy? 🧐 Dropbox servers can NOT know is particular action got intended by you or not! Once token authentication is Ok, everything is Ok (Dropbox servers point of view). Don't forget this!

oatcake

Thanks again for the reply. I understand your advice regarding the tokens.

I'm specifically asking how to go about allowing access to multiple end-users, that are securely logged into my app, to access the same Dropbox account taking into consideration the following quote that alluded to it being possible, 'do you 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'.

Perhaps Greg-DB could shine some light on this as he left the comment in this thread https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/API-Newbie-Authenticating-and-using-on-client-side-while-keeping/m-p/527479

Здравко

@oatcake wrote:
...
I'm specifically asking how to go about allowing access to multiple end-users, that are securely logged into my app, to access the same Dropbox account ...

Hi @oatcake,

Seems you haven't read carefully my previous posts above. Ok, your account is identified and authenticated with corresponding tokens. You need to pass to the client a regular access token, at least. If the user session can get prolonged for more than 4 hours, then refresh token have to be passed too. Once token(s) is/are available, you can initialize a client object and... perform whatever needed (all desired actions in your application). 😉 That's it.

Just take care while token transfer and keeping in the user browser session (where they can be popped from easily).

Hope this helps.

Brogers

Hello @oatcake ,

No this is not something we support nor is it something you should be doing to ensure the Dropbox account remains secure. If the end goal is that every user that submits a form, it creates a Dropbox file on a single account, it should not be done entirely client-side. If you do it all client-side, it would be exposing the access token to that Dropbox account and thus anyone could use that to make calls on behalf of that user.

An approach that would remove this risk would be to make these calls from a backend. Essentially, you would send the form data to the backend and the backend (which would have access to the token), would then upload this data to Dropbox thus removing the ability for the client-side users to access the Dropbox account directly.

If you are looking for an entirely client-side solution, there are plenty of form services that can upload results to a central location (although I don't know of any specifically that would upload to Dropbox).

Thanks,

Brad

oatcake

Thanks for the replies 😎

I think I understand what I need to do now to make things secure. Firebase hosting offers serverless Cloud Functions that 'lets you automatically run backend code in response to events triggered by Firebase features and HTTPS requests'. So I think I can utilise them to either send the form on the backend or perhaps send the form on the front end still but pull an access token from the backend via a request using a refresh token...I think that makes sense anyway. If it doesn't please let me know

I am a big programming newbie and have never dabbled with backend so thank you for breaking things down for me to think about.