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: notifications-unsubscr...@apisix.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org