-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Claim-based rate limiting #1587
Comments
Hi Pratik! After team discussion we've decided to accept the issue! We agree that current Header solution is ugly. We must switch to Remote IP to detect client's identity for anonymous routes... I have no idea when we will start development, I hope in January'24. We still have a couple of professional senior developers who write high quality code... So, any your contributions are really welcomed! |
Hello all, What is the specification for the configuration if we want to use a claim value as clientId ? Let me know if I should work on this ;p |
Hi Raman, Thank you for accepting this proposal. I Apologise, for the delay in reply. I am ready to work on this improvement, but let's clear the scope of this feature first. I was suggested to implement claim-based rate-limiting for authenticated routes. For anonymous/unauthenticated routs we can relay on Remote IP as you suggested. Let me know if any changes in these requirements. |
I think we should add a new property in RateLimitOptions like Seems good to you ? |
@ArchPratik You are assigned! Please start development!
Correct! But why not do discuss more?.. |
Dear @ArchPratik, |
New Feature
Extracting claims from the token and use as a Client ID in the rate limiting.
Suggesting a new feature to implement the rate limiting based on the claims in the token.
Motivation for New Feature
Current rate limiting is based on the Client ID passed in the header from the request. There are chances that anyone can manipulate the request by updating headers and using APIs without any restriction.
So, instead of depending on the consumer to provide the
Client ID
in the header, we can use the claims from the token. Which is more secure and not modifiable. Considering this, a rate limit will be applicable for authenticated endpoints only.Specifications
The text was updated successfully, but these errors were encountered: