-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Spring Cloud Gateway - How to implement Rate Limiter not by Key, but by Class of User #3578
Comments
That would be something you implement in your key relsover, we have no way of doing that. |
Ok I see. |
That's all specific to your application and I have no way of helping with it. |
Ok - I wonder how other companies do it. I'll look into it. |
Hi,
I'm currently trying to implement a Rate Limiter on my AWS infrastructure.
Requests for my app currently go through Spring Cloud Gateway (which does circuit breaking, retries, rate limiting, and a timeout)
My rate limiter code looks like this:
It is fairly simple with rate limiting done by a key present in the request (in my case session cookie id)
Now, what if I wanted to have different rate limits, by "classes of users" e.g. (premium, basic, admin_user, normal_user)
How would I do that using SCG? I tried exploring AWS API Gateway as they have something called Usage Plans for Rate limiting, but it didn't make sense having two Gateways, AWS API Gateway + Spring Cloud Gateway
My SCG does do authorization, so does get an access token from Auth0 by Okta, and store that in redis.
In theory, like API Gateway has a Lambda Authorizer, I could verify the token in the SCG, to get e.g. the ROLE of a user, and based on that use different rate limiters.
But I have been told that verifying an access token in both the SCG, and Spring Rest API behind it, is bad practice. (currently the access token sent by the SCG app is verified by the Spring Rest API only (using Spring Security Resource Server. SCG uses Spring Security Client, to get the access token only from Auth0 by Okta)
Or should I just try to use AWS API Gateway?
Any help to the above would be appreciated
The text was updated successfully, but these errors were encountered: