patilvamsi opened a new issue, #11918:
URL: https://github.com/apache/apisix/issues/11918
### Description
**Description:**
I would like to enhance the `limit-count` plugin to support using a
jwt-claim value as a `key`.
### Problem Statement
Currently, the `limit-count` plugin supports only static keys like `"var",
"var_combination", "constant"`. However, many real-world scenarios require
dynamic rate limiting based on contexts like specific users, tenants, or roles.
This capability is particularly relevant when using JWT tokens, as they can
contain such contextual information.
### Importance
Adding support for JWT claims as keys in the `limit-count` plugin provides
more flexibility in managing API usage. This feature makes it possible to
enforce rate limits dynamically based on JWT content, thereby catering to
various business use cases such as:
- **Per-User Rate Limiting**: Controlling API access for individual users.
- **Tenant-Specific Limits**: Enforcing resource usage restrictions at the
tenant level.
- **Role-Based Rate Controls**: Applying limits depending on user roles.
- **Claim-Based Customization**: Leveraging any claim from the JWT token to
implement fine-grained rate limiting.
### Solution Approach
To achieve this, I propose the following enhancements:
1. **JWT Claim-Based Key Type**
A new key type, `jwt_claim`, will be introduced. When this key type is
selected, the plugin will dynamically extract the specified claim from the JWT
token using the in-house JWT library:
```lua
local jwt = require("resty.jwt")
```
If `key_type` is configured as `"jwt_claim"`, the plugin will decode the
token and use the claim value as the rate-limiting key:
```lua
if conf.key_type == "jwt_claim" then
local decoded_token, err = jwt:verify(nil, token)
key = decoded_token.payload[conf.key]
end
```
Here, `conf.key` specifies the claim field to be used for rate limiting.
2. **Optional Enhancement: Remaining Time in Error Messages**
To improve the user experience, the plugin can dynamically include the
remaining reset time in the error message. If `$reset_in` is present in the
`rejected_msg` configuration, it will be replaced with the actual time
remaining:
```lua
local reset_in = string.gsub(conf.rejected_msg, "%$reset_in",
resetTimeInSeconds)
return conf.rejected_code, { error_msg = reset_in }
```
**Example Output:**
```json
{
"error_msg": "Too Many Requests. Please retry after 476 seconds."
}
```
Although the headers already provide reset time details, including it in
the error message makes the information more accessible and user-friendly.
### Benefits
- **Dynamic Context-Based Limits**: Supports user, tenant, and role-specific
rate limiting.
- **Backward Compatibility**: The default behavior remains unchanged.
- **Improved User Experience**: Clearer feedback through enhanced error
messages.
Do you think this change is suitable for a PR?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
