Open TheFiZi opened 8 years ago
Each paste has a single key. Hence we still need to create multiple pastes (each with a separate key, salt, etc.). I don't think this should be a mainline feature, but I will try to look into a JS-only solution for this after the upcoming release.
Right. I expected that this feature would simply shorten the work flow from:
To:
I fully expected each paste to have a unique URL.
I think the past needs to be encrypted and uploaded multiple times. It should certainly be possible to do this in JS...
Nice idea, BTW. The alternative to this would be to limit the amount of accesses a pad can get instead of only "expires on first access" we could optionally allow "expires on 5th access". This way you would only have to share one URL and it would fit your use case, @TheFiZi, would not it?
If so, which solution do you like more?
@rugk That is also a good idea.
The paranoid part of me prefers one URL per. When ever I send someone a password in a paste I tell them if the page doesn't load to let me know right away because someone other than them has likely accessed it and we need to change the password.
If we allowed 'x' accesses it's possible one of the people receiving the link might never bother to collect the password (shocking right?) and we'd never know if someone else used up their "access" or if it naturally expired.
While looking into this request I realized that either we would need a new API call to provide multiple creation requests in one call, which opens up a possibility to circumvent the traffic limiter, or you actually need to wait the traffic limit timeout in between API creation calls. Or you would decrease the traffic limit wait on your install (maybe an option if its just internal anyway).
Is this feature still valuable, if you would need to wait longer if you create more pastes?
Example: You use a server with the default 10 seconds between calls, hence creating 5 pastes takes a bit over 40 seconds.
I think the feature would still be useful if you had to wait the default delay between pastes as long as the interface clearly shows something like "Please wait, generating your URLs" with a ETA on it. Then when the process is complete you get a single page with the list of URLs.
Personally I'd rather wait 40 seconds to get 4 unique URLs than manually clone a paste 4 times.
What about offering another variant of the "clone" option (as a dropdown, possible) "generate another link", which clones the paste instantly without asking the user and generates a new link. This could also automatically detect the 10sec. thing and show a loading bar in this time…
@rugk That would work. Still a bit cumbersome unless you could specify a quantity as well.
Could add a few more items to the config file:
# How many multi-clones can be generated off a single paste
maxmulticlones=10
# How many multi-clones by a single client can bypass the default rate throttle
maxmulticlonesbypassthrottle=1
# How many seconds until someone can multi clone again
# Note: This throttle is separate from single paste throttle
multiclonethrottle=30
This would allow for instantly generating multiple URLs while still preventing someone from DDOS a deployment.
I'm just thinking of ways to reduce clicks.
The issue is we cannot detect "multi clones" on the server. Each clone has to be reencrypted (with a new key) and resent to the server, so we cannot even differentiate between one paste and multiple ones…
@rugk Ah gotcha. Well I'll take anything that makes making multiple unique URLs easier than manually clicking clone/send a bunch :)
We have a internal deployment of PrivateBin at work and use it to pass shared passwords between us.
I'd like to request a new feature that allows you to specify how many unique URLs to generate for a given paste instead of just one.
This would be a time saver instead of having to clone a paste over and over again to generate a unique, burn after reading, URL for each of my team mates.