You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
Let the recipient download the file/folder but remove the share after they got it. Expiration date only works if you know when they will get the file. This way you don't have to clean up share link.
Make sure the recipient and ONLY the recipient can download: sent link, check if person downloaded, link has disappeared already. Safe!
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.
Make sure the recipient and ONLY the recipient can download: sent link, check if person downloaded, link has disappeared already. Safe!
This is really a bogus argument. Because there are only 2 scenarios here:
The recipient shared the link with somebody. Which means they intend to have the file. If the download link would only work once they would just share it via other means.
You are afraid somebody guesses you share token. However, I would say if somebody has the time to guess a few septillion share tokens they can also just guess your password.
Check if the user downloading the file is really the user you sent the link to.
This would need some kind of authentication (e.g. pgp key validation)
You need to be sure the whole file got downloaded and no error occured on client side or the user gets locked out and you would have to re-submit the link. (Timeout, poor connection, browser crash)
Dunno if this would be possible with javascript to look at every aspect of file transfer
I remember mega(dot)nz does some kind of browser file caching, maybe hashing is possible to verify file integrity there
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:
We show an Activities thing when a file is downloaded. This doesn't trigger on preview generation does it? Perhaps the same thing that triggers the Activity can trigger the removal of the shared link.
a grace period makes sense in case a download went wrong. So once download is initiated, give it 10 minutes at least (and until the next Cron run, hehe).
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...
Reacted by Markus Raab, jiri-novacek, Klaas De Smedt, Jean-Philippe SARDA, Kai, hul51u and ΓzgΓΌr Konstantin KazanΓ§Γ§Δ±
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.
Reacted by Simon L., sokai, Jean-Philippe SARDA and Moini
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.
@sorbaugh@AndyScherzinger Do you already have an idea regarding that? Would indeed make sense to just integrate that.
(We did discuss this issue in Files planning, it's just not on the board yet, right? :)
We did discuss this issue in Files planning, it's just not on the board yet, right?
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.
So I had a look at this again and my recommendation would be to bundle the files_downloadlimit app with server.
After that is done, the UX could be improved by moving the setting to the advanced sharing settings for link shares, since the current placement is suboptimal:
Remove it from here
Move it here
As a second follow-up, it would be great to add an admin setting so that the admin can set a default to 1 for example.
Reacted by Moini, sunjam, Jan C. Borchardt and ΓzgΓΌr Konstantin KazanΓ§Γ§Δ±
Activity
rullzer commentedon Oct 16, 2017
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:
supremesyntax commentedon Nov 16, 2017
Thought about that some time ago...
You are running into several problems here:
Check if the user downloading the file is really the user you sent the link to.
This would need some kind of authentication (e.g. pgp key validation)
You need to be sure the whole file got downloaded and no error occured on client side or the user gets locked out and you would have to re-submit the link. (Timeout, poor connection, browser crash)
Dunno if this would be possible with javascript to look at every aspect of file transfer
I remember mega(dot)nz does some kind of browser file caching, maybe hashing is possible to verify file integrity there
LawnSounds commentedon Nov 26, 2017
Have a look at how Firefox Send works maybe? Open source. Would be great to see this feature!
jospoortvliet commentedon Dec 11, 2017
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...
[-]Feature request: offer one-time download links[/-][+]Offer one-time download links[/+][-]Offer one-time download links[/-][+]One-time download links[/+]jpfleury commentedon Dec 29, 2019
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:
grumpybozo commentedon Jan 17, 2020
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.
armijnhemel commentedon Apr 15, 2020
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.
jumpswitch commentedon May 10, 2020
I vote for that feature too.
In mission impossible style it would be like: this nextcloud share will self destruct after one download :)
18 remaining items
szaimen commentedon Jan 22, 2024
@jancborchardt since you have put this on the
Design Phaselist, why not simply integrating https://github.com/nextcloud/files_downloadlimit into core then? Not sure what we need to design then here?jancborchardt commentedon Jan 22, 2024
@sorbaugh @AndyScherzinger Do you already have an idea regarding that? Would indeed make sense to just integrate that.
(We did discuss this issue in Files planning, it's just not on the board yet, right? :)
AndyScherzinger commentedon Jan 22, 2024
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.
[-]One-time download links[/-][+]1οΈβ£β¬οΈπ One-time download links[/+]szaimen commentedon Feb 2, 2024
So I had a look at this again and my recommendation would be to bundle the files_downloadlimit app with server.
After that is done, the UX could be improved by moving the setting to the advanced sharing settings for link shares, since the current placement is suboptimal:
As a second follow-up, it would be great to add an admin setting so that the admin can set a default to 1 for example.
sorbaugh commentedon Feb 14, 2024
Edited original comment to split this issue into individual subtasks.
szaimen commentedon Mar 8, 2024
πππππ