🔐 Securely share sensitive information with automatic expiration & deletion after a set number of views or duration. Track who, what and when with full audit logs.
It should be possible to create and expire secrets (passwords, files, URLs) in bulk operation.
🔈 Motivation
Currently, a client in need of many operations at a time has to make sure to deal with rate limits appropriately. This effectively means intentional delays on the client side in order not to hit the rate limiter.
🛰 Alternatives
The current workaround is either
sleeping in the client, which can take quite a while with few hundred secrets (at the moment, might be more in the future) and a default rate limiter of 20 items per second
cranking up the rate limits. This is only viable for self hosted instances obviously, and is maybe not a good idea in general.
Following the last bullet point, it might be an option as well to be able to exclude single IP addresses (i.e. the one that the API client is running on).
📎 Additional context
In my option, this should be accompanied by some safety mechanisms for public instances, in order to not allow anonymous users to flood the system with millions of useless passwords or even abuse the system for some kind of other data transfer. But for self hosted instances, admins should have the ability to lower these guards to a level appropriate for the application, even when scaling to a larger setup.
🚀 Feature Request
It should be possible to create and expire secrets (passwords, files, URLs) in bulk operation.
🔈 Motivation
Currently, a client in need of many operations at a time has to make sure to deal with rate limits appropriately. This effectively means intentional delays on the client side in order not to hit the rate limiter.
🛰 Alternatives
The current workaround is either
Following the last bullet point, it might be an option as well to be able to exclude single IP addresses (i.e. the one that the API client is running on).
📎 Additional context
In my option, this should be accompanied by some safety mechanisms for public instances, in order to not allow anonymous users to flood the system with millions of useless passwords or even abuse the system for some kind of other data transfer. But for self hosted instances, admins should have the ability to lower these guards to a level appropriate for the application, even when scaling to a larger setup.