Feature request: ability to set a default Max-Downloads and Max-Days

[danfinn]

For my use case it would be really useful if it was possible to set a default for Max-Downloads and Max-Days so that it doesn't have to be specified with every upload. Is this possible?

[aspacca]

hello @danfinn

are you talking about a self-host instance of transfer.sh are you?

regarding a default Max-Days value set on the server side, this is the equivalent of setting purge-days (ie: number of days after the uploads are purged automatically)

[danfinn]

Hi @aspacca this would be for self hosted. I suppose that would work for a default setting of Max-Days, what I'm more interested in is a default setting for Max-Downloads.

[aspacca]

@danfinn

set a default for Max-Downloads and Max-Days so that it doesn't have to be specified with every upload. Is this possible

it seems something that's more related to the client side of the request
how do you upload the files in first place? a shell alias won't be sufficient for that?

[danfinn]

Setting it on the client side allows people to change it or tweak it to set it to whatever they want. We would like the ability to force it (or at least set a default so that if it's not set by the client) to 1 day for example.

[aspacca]

We would like the ability to force it (or at least set a default so that if it's not set by the client) to 1 day for example.

if we are talking about Max-Days and the rention of the files on the server, you have purge-days for that

it a little more unclear to me what's the goal, server side, to set Max-Downloads, considering that will just prevent the file to be downloaded, but it will not remove the file from the server

[danfinn]

Sorry, you are correct. I wasn't thinking correctly, it's been a while since I posted this. What we would really like is to be able to enforce a limit on downloads. Essentially we are looking for a secure place to upload a file that can only be downloaded once (or however many times we set in the config).

We would be using this in the same way we leverage another project called One Time Secret:
https://onetimesecret.com/

With that you share a secret with someone but they can only see it once and then it's gone. We would like to be able to accomplish the same thing with file transfers using transfer.sh.

[aspacca]

With that you share a secret with someone but they can only see it once and then it's gone. We would like to be able to accomplish the same thing with file transfers using transfer.sh.

oki, got it

I'd suggest that if a Max-Download is set on the server side, it cannot be set/it is ignored if set on the client side.
and the fact that it's set on server side must be informed from the frontend: similarly like now you have the information about the purge time

@stefanbenten what do you think?

[stefanbenten]

I think having the possibility of enforcing Max-Download or Max-Days is neat, however i do agree that it would need some frontend changes to make users aware of it.
Does your use case need the Web Interface? @danfinn
If not, it would definitely make things easier and could be approached from the angle that there are users wanting to disable the web interface anyway. That would mean, we enable an API-only mode, with the ability to then enforce these settings?

[Martinligabue]

I would add the use case of a small self-hosted server that doesn't have a lot of disk space, and having a hard time limit would help clean up old files.

Edit: I see there's the PURGE_DAYS envvar, so that already has a way to be solved, can the other problem be solved in the same way?

[aspacca]

@Martinligabue , yes, you are right, PURGE_DAYS is the way to go to purge (doh!) old/stale files from the storage

beware that Max-Donwloads and Max-Days do not execute any deletion of the files: they just prevent them to be downloaded.

the case for @danfinn was to be able to force a Max-Downloads server side: I'm still a little bit skeptical about this

btw, @danfinn : if you have a proxy like nginx or similare in front of the service you can just add/rewrite the headers there