Skip to content

1οΈβƒ£β¬‡οΈπŸ”— One-time download linksΒ #6841

Closed

Description

@jospoortvliet

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!

Activity

  1. rullzer commented on Oct 16, 2017

    @rullzer
    Member

    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.

    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:

    1. 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.
    2. 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.
  2. supremesyntax commented on Nov 16, 2017

    @supremesyntax

    Thought about that some time ago...

    You are running into several problems here:

    1. 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)

    2. 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

  3. LawnSounds commented on Nov 26, 2017

    @LawnSounds

    Have a look at how Firefox Send works maybe? Open source. Would be great to see this feature!

  4. jospoortvliet commented on Dec 11, 2017

    @jospoortvliet
    MemberAuthor

    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...

  5. changed the title [-]Feature request: offer one-time download links[/-] [+]Offer one-time download links[/+] on Jan 26, 2018
  6. changed the title [-]Offer one-time download links[/-] [+]One-time download links[/+] on Jan 26, 2018
  7. ghost removed
    staleTicket or PR with no recent activity
    on Jun 12, 2019
  8. jpfleury commented on Dec 29, 2019

    @jpfleury

    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:

  9. grumpybozo commented on Jan 17, 2020

    @grumpybozo

    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.

  10. armijnhemel commented on Apr 15, 2020

    @armijnhemel

    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.

  11. jumpswitch commented on May 10, 2020

    @jumpswitch

    I vote for that feature too.
    In mission impossible style it would be like: this nextcloud share will self destruct after one download :)

  12. 18 remaining items

  13. szaimen commented on Jan 22, 2024

    @szaimen
    Contributor

    @jancborchardt since you have put this on the Design Phase list, why not simply integrating https://github.com/nextcloud/files_downloadlimit into core then? Not sure what we need to design then here?

  14. self-assigned this
    on Jan 22, 2024
  15. jancborchardt commented on Jan 22, 2024

    @jancborchardt
    Member

    @jancborchardt since you have put this on the Design Phase list, why not simply integrating https://github.com/nextcloud/files_downloadlimit into core then? Not sure what we need to design then here?

    @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? :)

  16. AndyScherzinger commented on Jan 22, 2024

    @AndyScherzinger
    Member

    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.

  17. changed the title [-]One-time download links[/-] [+]1οΈβƒ£β¬‡οΈπŸ”— One-time download links[/+] on Jan 22, 2024
  18. szaimen commented on Feb 2, 2024

    @szaimen
    Contributor

    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
    image image

    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.

  19. moved this from πŸ“ Design phase to πŸ—οΈ At engineering in πŸ– Design teamon Feb 2, 2024
  20. added this to the Nextcloud 29 milestone on Feb 2, 2024
  21. sorbaugh commented on Feb 14, 2024

    @sorbaugh
    Contributor

    Edited original comment to split this issue into individual subtasks.

  22. moved this from πŸ—οΈ At engineering to πŸŽ‰ Done in πŸ– Design teamon Mar 8, 2024
  23. szaimen commented on Mar 8, 2024

    @szaimen
    Contributor

    πŸŽ‰πŸŽ‰πŸŽ‰πŸŽ‰πŸŽ‰

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions