Child Item

Correct way to use "add_file_member" endpoint if I need to share a file with a new email

Hello,

I am looking for a solution to my problem.

I am still in a testing stage, so I am open to different solution.

I need to share a file with only users who subscribe to a form. They subscribe on my website with their email and I add the email to the file requested.

To do that I thought the "add_file_member" endpoint could be the solution.

Actually I have two issues:

1. Access need to be temporary (I thought to flush email at scheduling), so I am not sure if "add_file_member" could suites my needs. Maybe "get_temporary_link" could work better? Does "get_temporary_link" allows download only to authorized emails? How long does the link last?

2. I was testing with the access token, but I did not get it lasts only for 4 hours. Still I do not need users to get OAuth, because I (the file owner) am the only one to give access to the file with the email provided. Does it sounds weird? Because I cannot find a simple solution that does not involve the user in an unnecessary authorization process since I am the one who has to give access and not them to log in.

Could you suggest a way to achieve what I want or point my errors?

Thanks!

Find more posts tagged with

API

Abuse

Comments

Greg-DB

1. The /2/sharing/add_file_member endpoint allows you to share specific files with specific users. That access does not expire automatically, but you can programmatically revoke it whenever you need using the /2/sharing/remove_folder_member endpoint.

Alternatively, the /2/files/get_temporary_link endpoint returns a temporary direct link to the file data. You can pass that link to users to allow them to access the file data. These links automatically expire after four hours. These do not enforce access to only users with specific email addresses.

2. This is the expected behavior for new access tokens. Dropbox is no longer offering the option for creating new long-lived access tokens. Dropbox is now issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.

Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. You can find more information in the OAuth Guide and authorization documentation. There's a basic outline of processing this flow in this blog post which may serve as a useful example.

lezan

Hello @Greg-DB,

thanks for the fast reply.

I mostly get all, but still I do not quite understand OAuth process and why I need it.

Let me get you an idea about my needs and flow:

1. User land on a page and submit a form with his email.

2. I handle the request with an API function, make a call to the Dropbox endpoint and share the file (I am the owner of the file) with the new email.

3. Send an email to the user with the download link.

I do not want the user to login/using their credentials, that's need to be transparent to the final user. Doesn't OAuth implicitly require the user to follow a process with their credentials to be authorized?

Thanks for the answer!

Greg-DB

The Dropbox OAuth app authorization flow is a way to have the user authorize the app to access their own Dropbox account. If your app is only meant for connecting to your own account, you would only need to process that flow once for your own account. You can store and re-use access tokens/refresh tokens for your own account. You would not need to expose that flow to other users.

Note that you should not expose any access tokens or refresh tokens for your own account to other users, e.g., keep your access tokens/refresh tokens on your server, and never send them to other users on your website front-end.

Здравко

@lezan wrote:
...
2. I handle the request with an API function, make a call to the Dropbox endpoint and share the file (I am the owner of the file) with the new email.
3. Send an email to the user with the download link.
...

Hi @lezan,

Hm...🤔 Can you clarify, why actually do you need both ways? In point 2 you're inviting a Dropbox user to shared file. In point 3 you're sending to person download link. They are 2 different way to do the (almost) same thing. In point 2, a Dropbox account (identified with the supplied email) is expected from recipient and login is expected in this context (the file gets up in the recipient account). In point 3 recipient doesn't need any Dropbox account, but on further file' changes re-download is needed (for most recent file version) - automatic sync is impossible. That's it. 😉 Choose what best matches your idea.

@lezan wrote:
... Doesn't OAuth implicitly require the user to follow a process with their credentials to be authorized?
...

OAuth is needed for you, not to the recipient! It's the only way to receive refresh token and, in this context, long term access. Otherwise, as Greg noted before, your access token will always expire 4 hours or so after generation.

Hope this sheds some light.

lezan

Hello @Greg-DB,

thanks for clarify.

That's what I was trying to point it out before: I not making app to let users access their account, but I only need to share my own file with users who provide their email.

I take some time to find how to achieve what you mention and I will get back to Accept the solution.

Hello @Здравко,

I tried to simplify the process and I did not mentioned that I am using transactional emails templated with all information I need to send. So the URL it is just a small part of the information. An user subscribe providing his email and at this point I make the file available for download to him adding his email to my file. Then I send a transactional email with the URL and other information.

I am not requiring an user to login with a Dropbox account. They will not sync any file, just download it. Maybe the term "share" I used it is not the most accurate.

Thanks for the support!