Copilot commented on code in PR #2134:
URL: https://github.com/apache/apisix-website/pull/2134#discussion_r4228712187
##########
website/learning-center/api-gateway-security.md:
##########
@@ -116,6 +116,28 @@ For **mutual TLS**, APISIX supports [mTLS
configuration](/docs/apisix/mtls/) for
APISIX also supports JWT authentication, key authentication, OpenID Connect,
rate limiting with multiple algorithms, and request body validation. Its plugin
architecture lets teams compose gateway policies per route while retaining
application-level authorization and validation in the services that own the
data.
+### Example: Authenticate and Rate-Limit a Route
+
+For a protected API, first create a Consumer with a `key-auth` Credential.
Then enable [key-auth](/docs/apisix/plugins/key-auth/) and
[limit-count](/docs/apisix/plugins/limit-count/) on the Route. This example is
a plugin configuration excerpt for a Route that already has an Upstream; adjust
the quota to the backend's capacity and the client contract:
+
+```json
+{
+ "key-auth": {
+ "hide_credentials": true
+ },
+ "limit-count": {
+ "count": 100,
+ "time_window": 60,
+ "rejected_code": 429,
+ "key_type": "var_combination",
+ "key": "$remote_addr $consumer_name",
+ "policy": "local"
Review Comment:
The JSON example is presented as “a plugin configuration excerpt for a
Route”, but as written it looks like a full Route body (it’s missing the
`plugins` wrapper field that Route schemas expect). To prevent copy/paste
failures, either wrap this under a `plugins` key (and optionally show a minimal
Route skeleton), or explicitly state that the snippet is the value of the
Route’s `plugins` field (not the whole Route object).
##########
website/learning-center/api-gateway-security.md:
##########
@@ -116,6 +116,28 @@ For **mutual TLS**, APISIX supports [mTLS
configuration](/docs/apisix/mtls/) for
APISIX also supports JWT authentication, key authentication, OpenID Connect,
rate limiting with multiple algorithms, and request body validation. Its plugin
architecture lets teams compose gateway policies per route while retaining
application-level authorization and validation in the services that own the
data.
+### Example: Authenticate and Rate-Limit a Route
+
+For a protected API, first create a Consumer with a `key-auth` Credential.
Then enable [key-auth](/docs/apisix/plugins/key-auth/) and
[limit-count](/docs/apisix/plugins/limit-count/) on the Route. This example is
a plugin configuration excerpt for a Route that already has an Upstream; adjust
the quota to the backend's capacity and the client contract:
+
+```json
+{
+ "key-auth": {
+ "hide_credentials": true
+ },
+ "limit-count": {
+ "count": 100,
+ "time_window": 60,
+ "rejected_code": 429,
+ "key_type": "var_combination",
+ "key": "$remote_addr $consumer_name",
+ "policy": "local"
+ }
+}
+```
+
+The counter key combines the address APISIX observes and the authenticated
Consumer name, so the quota applies to each pair, not to each Consumer across
all addresses. Behind a proxy, that address may be the proxy's; configure a
[trusted real-IP source](/docs/apisix/plugins/real-ip/) if the quota must use
the original client address. With `policy: local`, each APISIX instance keeps
its own counters; use an appropriate shared Redis policy when a quota must
apply across instances. `hide_credentials` keeps the API key out of the
upstream request. This gateway policy does not decide whether the authenticated
Consumer may access a particular order or account: the application must still
check resource ownership.
Review Comment:
This paragraph contains several distinct, easy-to-miss caveats (quota
scoping, proxy IP behavior, per-instance counters vs shared store, credential
forwarding, and authz boundaries) in a single block. Converting it into a short
bullet list (one item per caveat) would make the operational constraints more
scannable and reduce the likelihood readers miss an important detail.
##########
website/learning-center/api-gateway-security.md:
##########
@@ -116,6 +116,28 @@ For **mutual TLS**, APISIX supports [mTLS
configuration](/docs/apisix/mtls/) for
APISIX also supports JWT authentication, key authentication, OpenID Connect,
rate limiting with multiple algorithms, and request body validation. Its plugin
architecture lets teams compose gateway policies per route while retaining
application-level authorization and validation in the services that own the
data.
+### Example: Authenticate and Rate-Limit a Route
+
+For a protected API, first create a Consumer with a `key-auth` Credential.
Then enable [key-auth](/docs/apisix/plugins/key-auth/) and
[limit-count](/docs/apisix/plugins/limit-count/) on the Route. This example is
a plugin configuration excerpt for a Route that already has an Upstream; adjust
the quota to the backend's capacity and the client contract:
+
+```json
+{
+ "key-auth": {
+ "hide_credentials": true
+ },
+ "limit-count": {
+ "count": 100,
+ "time_window": 60,
+ "rejected_code": 429,
+ "key_type": "var_combination",
+ "key": "$remote_addr $consumer_name",
Review Comment:
This example relies on `$consumer_name` being populated when `limit-count`
runs. If `limit-count` executes before authentication in the request
phases/priorities, `$consumer_name` may be empty and the effective limit key
can collapse to “per-address only” (or even a shared bucket for unauthenticated
traffic), which can change quota semantics and affect reliability under abuse.
Consider adding a brief note that the counter key depends on auth having run
first, and/or point readers to an alternative key strategy (e.g., consumer-only
keys when the intent is per-consumer) to avoid accidental misconfiguration.
--
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]
