mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-03-02 22:57:18 -05:00
Add rate limiting to the API #489
Labels
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#489
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ntimo on GitHub (Nov 13, 2019).
Hello,
first off awesome project. I just took a look at the official bitwarden API and saw that it has a rate limit. I would like suggest to add a rate limit too. It should probably use the same headers like the official one:
What do you think about that? Maybe the limit could also be made configurable using a environment variable.
@dani-garcia commented on GitHub (Nov 14, 2019):
So far we've intentionally kept out of this space because it's reasonably easy to do with external tools while it could be quite complex to implement correctly and at the same time it would require a lot of configurability because no one wants the exact same setup. For example, someone might prefer to only ratelimit the login endpoint, or apply different limits to loggedin users vs anonymous users, someone might want to ban the users after the limit is reached, others might want to block them for a certain time, someone could want more restrictive limits for some IP range or more relaxed for the local LAN...
Personally I wouldn't mind some basic ratelimiting being built in, but a more robust solution would be to create documentation on how to integrate bitwarden_rs with the rate limiting of third party proxies or firewalls.
@BlackDex commented on GitHub (Oct 8, 2020):
To keep the issue tracker more focused, I'm closing this issue in favor of the meta issue at #246