-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1️⃣⬇️🔗 One-time download links #6841
Comments
First of all. It is not so simple. Because a link is accessed via webdav as well. So just opening the link is already the first access. Then downloading it is the second access. Or if they navigate in the structure it is all access. Or what hapens when they have a client that previews the page or something? It is all access.
This is really a bogus argument. Because there are only 2 scenarios here:
|
Thought about that some time ago... You are running into several problems here:
|
Have a look at how Firefox Send works maybe? Open source. Would be great to see this feature! |
Well, the use case I think is clear: you create a public link and want it to go away once the recipient has downloaded the file, without having to go and check up with that person. Some thoughts:
I personally frequently share files by public link for a one-time use case: a screenshot you want to show and other stuff. Automatic cleanup of those links would be nice... |
Someone mentioned Firefox Send as offering one-time download links. There are also some other open source projects to look at with this feature. Examples: |
This feature and the simpler feature requested in #17934 would be useful and I'd like to see them both. Currently it is not even clear when expiration actually happens, i.e. is it 00:00 UTC? 00:00 in the user's local time zone when setting the expiration? Some other arbitrary time? My context for this is that we use shared links to communicate initial passwords to users. We'd like these to die when they are no longer needed but no sooner. That is obviously not determinable programmatically, so at least knowing precisely when a link expires (with a fixed time or after a certain number of accesses or something more complex but deterministic) would help. |
I would be interested in such functionality. For me it would be enough to drop the guarantee that the client has actually received the data: as soon as the server has sent the data, it should be considered to have been downloaded and the data should be removed after 1 or N downloads. If the client didn't get it: tough luck, wait for a complaint and resend. I think that this would make it less difficult to implement. |
I vote for that feature too. |
Just adding my two cents to this. I think this feature is severely needed. |
Agree, this is a very useful feature, to say the least. |
Same here would be interested |
Would be nice to share Passwords and Certificates |
Maybe, an expiration period after the first download? a default of 24 hours seems reasonable I think to cover errors during download and gives the users some time to retry. |
@szaimen I've seen that app, however, as for many useful apps, it said it wasn't available for my version when I looked (now it is, and I'll install it). And to find it... well, it cannot be found from the search field, nor is there a separate app search - and apps also aren't strictly ordered by alphabet. You need to know the category to find something... UX is making it so difficult... |
The app @szaimen pointed out looks good, but I am going to add to the argument for it becoming a core feature. The problem it solves is this: someone has asked you to email a sensitive document. Example: an apartment rental application. Email is not always encrypted in transit, and you or the recipient could be compromised and have your inbox/sentbox exposed. This feature limits the damage. Limiting the download window to the absolute minimum amount of time is key. It’s still possible that an attacker might access the link before the recipient. This is the worst case, but because of this feature, the recipient can infer that their denial means there was a compromise and the sender can be notified. That’s a further win for this feature that an expiration date cannot provide. |
@szaimen What would you consider a strong reason to not make it core? |
It's a new year, which means U.S. tax season is coming up again. I'd like to be able to email my tax documents to my tax accountant using this feature. For the exact reasons that @wickning1 pointed out, it would be much safer than an email attachment. |
@matthewmummert5 For that specific purpose, I'd probably share a password by phone or letter and use password protection. I do agree that a one-time / limited times download would be very useful for less sensitive data. |
@jancborchardt since you have put this on the |
@sorbaugh @AndyScherzinger Do you already have an idea regarding that? Would indeed make sense to just integrate that. |
Yes, right, added this issue now. And I would agree with @szaimen that download_limit would work for this while I can't say if we need some kind of UI improvements for a "one-time download" scenario when creating shares or if you would consider it "fine as is" (fance for "good enough") and we integrate it, while the cheapest solution would just be to bundle the app. Alternatively we can of course also thing about integration it into the core code base. |
Edited original comment to split this issue into individual subtasks. |
🎉🎉🎉🎉🎉 |
Sometimes you want to offer a download to a recipient, but have it work only once. An expiration date then doesn't do the trick.
Why would you want this?
The text was updated successfully, but these errors were encountered: