You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by "Yilialinn (via GitHub)" <gi...@apache.org> on 2026/04/17 06:24:50 UTC
[PR] docs(key-auth): re-port with Admin API, ADC, and Ingress Controller tabs [apisix]
Yilialinn opened a new pull request, #13241:
URL: https://github.com/apache/apisix/pull/13241
Re-ports the key-auth plugin documentation with Admin API, ADC, and Ingress Controller tab structure, updated attribute table, and canonical link.
--
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-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(key-auth): re-port with Admin API, ADC, and Ingress Controller tabs [apisix]
Posted by "Yilialinn (via GitHub)" <gi...@apache.org>.
Yilialinn commented on code in PR #13241:
URL: https://github.com/apache/apisix/pull/13241#discussion_r3116638142
##########
docs/zh/latest/plugins/key-auth.md:
##########
@@ -32,43 +32,43 @@ description: key-auth 插件支持使用身份验证密钥作为客户端在访
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## 描述
`key-auth` 插件支持使用身份验证密钥作为客户端在访问上游资源之前进行身份验证的机制。
-要使用该插件，您需要在 [Consumers](../terminology/consumer.md) 上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。然后，APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
+要使用该插件，您需要在[消费者](../terminology/consumer.md)上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
-当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Indentifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
+当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Identifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
## 属性
Consumer/Credential 端：
-| 名称 | 类型 | 必选项 | 描述 |
-| ---- | ------ | ------ | ------------------------------------------------------------------------------------------------------------- |
-| key | string | 是 | 不同的 Consumer 应有不同的 `key`，它应当是唯一的。如果多个 Consumer 使用了相同的 `key`，将会出现请求匹配异常。该字段支持使用 [APISIX Secret](../terminology/secret.md) 资源，将值保存在 Secret Manager 中。 |
-
-注意：schema 中还定义了 `encrypt_fields = {"key"}`，这意味着该字段将会被加密存储在 etcd 中。具体参考 [加密存储字段](../plugin-develop.md#加密存储字段)。
+| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
+|------|------|--------|--------|--------|------|
+| key | string | 是 | | | 标识消费者凭证的唯一密钥。密钥在存储到 etcd 之前会使用 AES 加密。您也可以将其存储在环境变量中并使用 `env://` 前缀引用，或存储在 HashiCorp Vault 等密钥管理器中并使用 `secret://` 前缀引用。 |
Route 端：
-| 名称 | 类型 | 必选项 | 默认值 | 描述 |
-| ----------------- | ------ | ----- | ------ |----------------------------------------------------------------------------------------------------------------------------------------------------------|
-| header | string | 否 | apikey | 设置我们从哪个 header 获取 key。 |
-| query | string | 否 | apikey | 设置我们从哪个 query string 获取 key，优先级低于 `header`。 |
-| hide_credentials | boolean | 否 | false | 如果为 `true`，则不要将含有认证信息的 header 或 query string 传递给 Upstream。 |
-| realm | string | 否 | key |在身份验证失败时，应包含在 `WWW-Authenticate` 标头中的域。|
+| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
+|------|------|--------|--------|--------|------|
+| header | string | 否 | apikey | | 获取密钥的请求标头名称。 |
+| query | string | 否 | apikey | | 获取密钥的查询字符串参数名称，优先级低于 `header`。 |
+| hide_credentials | boolean | 否 | false | | 若为 `true`，则不将含有认证信息的标头或查询字符串传递给上游服务。 |
+| anonymous_consumer | string | 否 | | | 匿名消费者名称。如果已配置，则允许匿名用户绕过身份验证。 |
+| realm | string | 否 | key | | 在身份验证失败时，`401 Unauthorized` 响应中 [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc7235#section-4.1) 标头的域值。该参数在 Apache APISIX 3.15.0 及以上版本中可用。 |
## 示例
以下示例演示了如何在不同场景中使用 `key-auth` 插件。
:::note
-您可以这样从 `config.yaml` 中获取 `admin_key` 并存入环境变量：
-
```bash
-admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')
+admin_key=$(yq '.deployment.admin.admin_key[0].key' /usr/local/apisix/conf/config.yaml | sed 's/"//g')
Review Comment:
Fixed — the ZH file now uses the relative path `conf/config.yaml` instead of the hardcoded absolute path.
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -32,51 +32,61 @@ description: The key-auth Plugin supports the use of an authentication key as a
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Description
The `key-auth` Plugin supports the use of an authentication key as a mechanism for clients to authenticate themselves before accessing Upstream resources.
-To use the plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on routes or services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
+To use the Plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on Routes or Services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
-When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Indentifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
+When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
## Attributes
For Consumer/Credential:
-| Name | Type | Required | Description |
-|------|--------|-------------|----------------------------|
-| key | string | True | Unique key for a Consumer. This field supports saving the value in Secret Manager using the [APISIX Secret](../terminology/secret.md) resource. |
-
-NOTE: `encrypt_fields = {"key"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See [encrypted storage fields](../plugin-develop.md#encrypted-storage-fields).
+| Name | Type | Required | Default | Valid values | Description |
+|------|------|----------|---------|--------------|-------------|
+| key | string | True | | | A unique key that identifies the Credential for a Consumer. The key is encrypted with AES before being stored in etcd. You can also store it in an environment variable and reference it using the `env://` prefix, or in a secret manager such as HashiCorp Vault's KV secrets engine, and reference it using the `secret://` prefix. |
Review Comment:
Fixed — updated the EN attributes table to use `$env://` and `$secret://` prefixes (with the leading `$`).
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -32,51 +32,61 @@ description: The key-auth Plugin supports the use of an authentication key as a
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Description
The `key-auth` Plugin supports the use of an authentication key as a mechanism for clients to authenticate themselves before accessing Upstream resources.
-To use the plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on routes or services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
+To use the Plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on Routes or Services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
-When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Indentifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
+When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
## Attributes
For Consumer/Credential:
-| Name | Type | Required | Description |
-|------|--------|-------------|----------------------------|
-| key | string | True | Unique key for a Consumer. This field supports saving the value in Secret Manager using the [APISIX Secret](../terminology/secret.md) resource. |
-
-NOTE: `encrypt_fields = {"key"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See [encrypted storage fields](../plugin-develop.md#encrypted-storage-fields).
+| Name | Type | Required | Default | Valid values | Description |
+|------|------|----------|---------|--------------|-------------|
+| key | string | True | | | A unique key that identifies the Credential for a Consumer. The key is encrypted with AES before being stored in etcd. You can also store it in an environment variable and reference it using the `env://` prefix, or in a secret manager such as HashiCorp Vault's KV secrets engine, and reference it using the `secret://` prefix. |
Review Comment:
Fixed — updated the EN attributes table with conditional AES wording: the description now states encryption only applies when `apisix.data_encryption.enable_encrypt_fields` is enabled and etcd is used as the config center. Also corrected the prefix to `$env://` and `$secret://`.
--
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-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(key-auth): re-port with Admin API, ADC, and Ingress Controller tabs [apisix]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #13241:
URL: https://github.com/apache/apisix/pull/13241#discussion_r3099158655
##########
docs/zh/latest/plugins/key-auth.md:
##########
@@ -32,43 +32,43 @@ description: key-auth 插件支持使用身份验证密钥作为客户端在访
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## 描述
`key-auth` 插件支持使用身份验证密钥作为客户端在访问上游资源之前进行身份验证的机制。
-要使用该插件，您需要在 [Consumers](../terminology/consumer.md) 上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。然后，APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
+要使用该插件，您需要在[消费者](../terminology/consumer.md)上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
-当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Indentifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
+当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Identifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
## 属性
Consumer/Credential 端：
-| 名称 | 类型 | 必选项 | 描述 |
-| ---- | ------ | ------ | ------------------------------------------------------------------------------------------------------------- |
-| key | string | 是 | 不同的 Consumer 应有不同的 `key`，它应当是唯一的。如果多个 Consumer 使用了相同的 `key`，将会出现请求匹配异常。该字段支持使用 [APISIX Secret](../terminology/secret.md) 资源，将值保存在 Secret Manager 中。 |
-
-注意：schema 中还定义了 `encrypt_fields = {"key"}`，这意味着该字段将会被加密存储在 etcd 中。具体参考 [加密存储字段](../plugin-develop.md#加密存储字段)。
+| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
+|------|------|--------|--------|--------|------|
+| key | string | 是 | | | 标识消费者凭证的唯一密钥。密钥在存储到 etcd 之前会使用 AES 加密。您也可以将其存储在环境变量中并使用 `env://` 前缀引用，或存储在 HashiCorp Vault 等密钥管理器中并使用 `secret://` 前缀引用。 |
Route 端：
-| 名称 | 类型 | 必选项 | 默认值 | 描述 |
-| ----------------- | ------ | ----- | ------ |----------------------------------------------------------------------------------------------------------------------------------------------------------|
-| header | string | 否 | apikey | 设置我们从哪个 header 获取 key。 |
-| query | string | 否 | apikey | 设置我们从哪个 query string 获取 key，优先级低于 `header`。 |
-| hide_credentials | boolean | 否 | false | 如果为 `true`，则不要将含有认证信息的 header 或 query string 传递给 Upstream。 |
-| realm | string | 否 | key |在身份验证失败时，应包含在 `WWW-Authenticate` 标头中的域。|
+| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
+|------|------|--------|--------|--------|------|
+| header | string | 否 | apikey | | 获取密钥的请求标头名称。 |
+| query | string | 否 | apikey | | 获取密钥的查询字符串参数名称，优先级低于 `header`。 |
+| hide_credentials | boolean | 否 | false | | 若为 `true`，则不将含有认证信息的标头或查询字符串传递给上游服务。 |
+| anonymous_consumer | string | 否 | | | 匿名消费者名称。如果已配置，则允许匿名用户绕过身份验证。 |
+| realm | string | 否 | key | | 在身份验证失败时，`401 Unauthorized` 响应中 [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc7235#section-4.1) 标头的域值。该参数在 Apache APISIX 3.15.0 及以上版本中可用。 |
## 示例
以下示例演示了如何在不同场景中使用 `key-auth` 插件。
:::note
-您可以这样从 `config.yaml` 中获取 `admin_key` 并存入环境变量：
-
```bash
-admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')
+admin_key=$(yq '.deployment.admin.admin_key[0].key' /usr/local/apisix/conf/config.yaml | sed 's/"//g')
Review Comment:
示例中读取 `admin_key` 的路径写死为 `/usr/local/apisix/conf/config.yaml`。仓库内多数文档使用相对路径 `conf/config.yaml`，并且不同安装方式（Docker、自定义安装目录等）该绝对路径可能不成立。建议保持相对路径或注明需要根据安装目录调整。
```suggestion
admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')
```
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -32,51 +32,61 @@ description: The key-auth Plugin supports the use of an authentication key as a
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Description
The `key-auth` Plugin supports the use of an authentication key as a mechanism for clients to authenticate themselves before accessing Upstream resources.
-To use the plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on routes or services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
+To use the Plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on Routes or Services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
-When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Indentifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
+When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
## Attributes
For Consumer/Credential:
-| Name | Type | Required | Description |
-|------|--------|-------------|----------------------------|
-| key | string | True | Unique key for a Consumer. This field supports saving the value in Secret Manager using the [APISIX Secret](../terminology/secret.md) resource. |
-
-NOTE: `encrypt_fields = {"key"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See [encrypted storage fields](../plugin-develop.md#encrypted-storage-fields).
+| Name | Type | Required | Default | Valid values | Description |
+|------|------|----------|---------|--------------|-------------|
+| key | string | True | | | A unique key that identifies the Credential for a Consumer. The key is encrypted with AES before being stored in etcd. You can also store it in an environment variable and reference it using the `env://` prefix, or in a secret manager such as HashiCorp Vault's KV secrets engine, and reference it using the `secret://` prefix. |
For Route:
-| Name | Type | Required | Default | Description |
-|--------|--------|-------------|-------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| header | string | False | apikey | The header to get the key from. |
-| query | string | False | apikey | The query string to get the key from. Lower priority than header. |
-| hide_credentials | boolean | False | false | If true, do not pass the header or query string with key to Upstream services. |
-| anonymous_consumer | string | False | false | Anonymous Consumer name. If configured, allow anonymous users to bypass the authentication. |
-| realm | string | False | key | The realm to include in the `WWW-Authenticate` header when authentication fails. |
+| Name | Type | Required | Default | Valid values | Description |
+|------|------|----------|---------|--------------|-------------|
+| header | string | False | apikey | | The header to get the key from. |
+| query | string | False | apikey | | The query string to get the key from. Lower priority than `header`. |
+| hide_credentials | boolean | False | false | | If true, do not pass the header or query string with key to Upstream services. |
+| anonymous_consumer | string | False | | | Anonymous Consumer name. If configured, allow anonymous users to bypass the authentication. |
+| realm | string | False | key | | Realm in the [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc7235#section-4.1) response header returned with a `401 Unauthorized` response due to authentication failure. Available in Apache APISIX version 3.15.0 and later. |
## Examples
The examples below demonstrate how you can work with the `key-auth` Plugin for different scenarios.
:::note
-You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command:
-
```bash
-admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')
+admin_key=$(yq '.deployment.admin.admin_key[0].key' /usr/local/apisix/conf/config.yaml | sed 's/"//g')
Review Comment:
The docs hardcode `/usr/local/apisix/conf/config.yaml` when extracting `admin_key`. Most other docs in this repo use the relative `conf/config.yaml`, and the absolute path may be wrong for non-default installs (Docker, custom prefix, etc.). Consider reverting to `conf/config.yaml` or explaining that the path depends on the installation directory.
```suggestion
admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')
```
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -32,51 +32,61 @@ description: The key-auth Plugin supports the use of an authentication key as a
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Description
The `key-auth` Plugin supports the use of an authentication key as a mechanism for clients to authenticate themselves before accessing Upstream resources.
-To use the plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on routes or services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
+To use the Plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on Routes or Services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
-When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Indentifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
+When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
## Attributes
For Consumer/Credential:
-| Name | Type | Required | Description |
-|------|--------|-------------|----------------------------|
-| key | string | True | Unique key for a Consumer. This field supports saving the value in Secret Manager using the [APISIX Secret](../terminology/secret.md) resource. |
-
-NOTE: `encrypt_fields = {"key"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See [encrypted storage fields](../plugin-develop.md#encrypted-storage-fields).
+| Name | Type | Required | Default | Valid values | Description |
+|------|------|----------|---------|--------------|-------------|
+| key | string | True | | | A unique key that identifies the Credential for a Consumer. The key is encrypted with AES before being stored in etcd. You can also store it in an environment variable and reference it using the `env://` prefix, or in a secret manager such as HashiCorp Vault's KV secrets engine, and reference it using the `secret://` prefix. |
Review Comment:
This statement implies the key is always AES-encrypted in etcd. In APISIX, encryption of `encrypt_fields` is only applied when `apisix.data_encryption.enable_encrypt_fields` is enabled (and config type is etcd). Consider wording it conditionally to avoid misleading users who disable field encryption.
```suggestion
| key | string | True | | | A unique key that identifies the Credential for a Consumer. When `apisix.data_encryption.enable_encrypt_fields` is enabled and the configuration is stored in etcd, the key is encrypted with AES before storage. You can also store it in an environment variable and reference it using the `env://` prefix, or in a secret manager such as HashiCorp Vault's KV secrets engine, and reference it using the `secret://` prefix. |
```
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -32,51 +32,61 @@ description: The key-auth Plugin supports the use of an authentication key as a
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Description
The `key-auth` Plugin supports the use of an authentication key as a mechanism for clients to authenticate themselves before accessing Upstream resources.
-To use the plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on routes or services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
+To use the Plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on Routes or Services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
-When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Indentifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
+When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
## Attributes
For Consumer/Credential:
-| Name | Type | Required | Description |
-|------|--------|-------------|----------------------------|
-| key | string | True | Unique key for a Consumer. This field supports saving the value in Secret Manager using the [APISIX Secret](../terminology/secret.md) resource. |
-
-NOTE: `encrypt_fields = {"key"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See [encrypted storage fields](../plugin-develop.md#encrypted-storage-fields).
+| Name | Type | Required | Default | Valid values | Description |
+|------|------|----------|---------|--------------|-------------|
+| key | string | True | | | A unique key that identifies the Credential for a Consumer. The key is encrypted with AES before being stored in etcd. You can also store it in an environment variable and reference it using the `env://` prefix, or in a secret manager such as HashiCorp Vault's KV secrets engine, and reference it using the `secret://` prefix. |
Review Comment:
The references to environment variables and secrets use the wrong URI prefixes. APISIX resolves env/secret references via `$ENV://...` (case-insensitive, so `$env://...` works) and `$secret://...`; without the leading `$` the value will be treated as a literal string and not resolved.
```suggestion
| key | string | True | | | A unique key that identifies the Credential for a Consumer. The key is encrypted with AES before being stored in etcd. You can also store it in an environment variable and reference it using the `$env://` prefix, or in a secret manager such as HashiCorp Vault's KV secrets engine, and reference it using the `$secret://` prefix. |
```
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -32,51 +32,61 @@ description: The key-auth Plugin supports the use of an authentication key as a
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Description
The `key-auth` Plugin supports the use of an authentication key as a mechanism for clients to authenticate themselves before accessing Upstream resources.
-To use the plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on routes or services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
+To use the Plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on Routes or Services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
-When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Indentifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
+When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
Review Comment:
Minor grammar: “implement additional logics” is unidiomatic in English; “implement additional logic” would read better.
```suggestion
When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logic as needed. If any of these values is not available, the corresponding header will not be added.
```
##########
docs/zh/latest/plugins/key-auth.md:
##########
@@ -32,43 +32,43 @@ description: key-auth 插件支持使用身份验证密钥作为客户端在访
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## 描述
`key-auth` 插件支持使用身份验证密钥作为客户端在访问上游资源之前进行身份验证的机制。
-要使用该插件，您需要在 [Consumers](../terminology/consumer.md) 上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。然后，APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
+要使用该插件，您需要在[消费者](../terminology/consumer.md)上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
-当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Indentifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
+当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Identifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
## 属性
Consumer/Credential 端：
-| 名称 | 类型 | 必选项 | 描述 |
-| ---- | ------ | ------ | ------------------------------------------------------------------------------------------------------------- |
-| key | string | 是 | 不同的 Consumer 应有不同的 `key`，它应当是唯一的。如果多个 Consumer 使用了相同的 `key`，将会出现请求匹配异常。该字段支持使用 [APISIX Secret](../terminology/secret.md) 资源，将值保存在 Secret Manager 中。 |
-
-注意：schema 中还定义了 `encrypt_fields = {"key"}`，这意味着该字段将会被加密存储在 etcd 中。具体参考 [加密存储字段](../plugin-develop.md#加密存储字段)。
+| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
+|------|------|--------|--------|--------|------|
+| key | string | 是 | | | 标识消费者凭证的唯一密钥。密钥在存储到 etcd 之前会使用 AES 加密。您也可以将其存储在环境变量中并使用 `env://` 前缀引用，或存储在 HashiCorp Vault 等密钥管理器中并使用 `secret://` 前缀引用。 |
Review Comment:
“密钥在存储到 etcd 之前会使用 AES 加密” 这句话看起来像是必然行为，但在 APISIX 中只有当 `apisix.data_encryption.enable_encrypt_fields` 开启（且使用 etcd 配置中心）时，`encrypt_fields` 才会触发加密。建议改为条件性描述，避免误导关闭加密字段的用户。
```suggestion
| key | string | 是 | | | 标识消费者凭证的唯一密钥。使用 etcd 作为配置中心且开启 `apisix.data_encryption.enable_encrypt_fields` 时，密钥在存储到 etcd 之前会使用 AES 加密。您也可以将其存储在环境变量中并使用 `env://` 前缀引用，或存储在 HashiCorp Vault 等密钥管理器中并使用 `secret://` 前缀引用。 |
```
##########
docs/zh/latest/plugins/key-auth.md:
##########
@@ -32,43 +32,43 @@ description: key-auth 插件支持使用身份验证密钥作为客户端在访
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## 描述
`key-auth` 插件支持使用身份验证密钥作为客户端在访问上游资源之前进行身份验证的机制。
-要使用该插件，您需要在 [Consumers](../terminology/consumer.md) 上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。然后，APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
+要使用该插件，您需要在[消费者](../terminology/consumer.md)上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
-当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Indentifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
+当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Identifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
## 属性
Consumer/Credential 端：
-| 名称 | 类型 | 必选项 | 描述 |
-| ---- | ------ | ------ | ------------------------------------------------------------------------------------------------------------- |
-| key | string | 是 | 不同的 Consumer 应有不同的 `key`，它应当是唯一的。如果多个 Consumer 使用了相同的 `key`，将会出现请求匹配异常。该字段支持使用 [APISIX Secret](../terminology/secret.md) 资源，将值保存在 Secret Manager 中。 |
-
-注意：schema 中还定义了 `encrypt_fields = {"key"}`，这意味着该字段将会被加密存储在 etcd 中。具体参考 [加密存储字段](../plugin-develop.md#加密存储字段)。
+| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
+|------|------|--------|--------|--------|------|
+| key | string | 是 | | | 标识消费者凭证的唯一密钥。密钥在存储到 etcd 之前会使用 AES 加密。您也可以将其存储在环境变量中并使用 `env://` 前缀引用，或存储在 HashiCorp Vault 等密钥管理器中并使用 `secret://` 前缀引用。 |
Review Comment:
这里提到的环境变量/密钥管理器引用前缀缺少开头的 `$`。APISIX 支持的格式是 `$env://...`（大小写不敏感，实际实现使用 `$ENV://`）和 `$secret://...`；如果写成 `env://`/`secret://` 会被当成普通字符串，无法解析。
```suggestion
| key | string | 是 | | | 标识消费者凭证的唯一密钥。密钥在存储到 etcd 之前会使用 AES 加密。您也可以将其存储在环境变量中并使用 `$env://` 前缀引用，或存储在 HashiCorp Vault 等密钥管理器中并使用 `$secret://` 前缀引用。 |
```
--
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-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(key-auth): re-port with Admin API, ADC, and Ingress Controller tabs [apisix]
Posted by "kayx23 (via GitHub)" <gi...@apache.org>.
kayx23 commented on code in PR #13241:
URL: https://github.com/apache/apisix/pull/13241#discussion_r3109763421
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -385,6 +1086,17 @@ You should see an `HTTP/1.1 200 OK` response. This shows that the key included i
The following example demonstrates how you can attach a Consumer custom ID to authenticated request in the `Consumer-Custom-Id` header, which can be used to implement additional logics as needed.
Review Comment:
This header name looks inconsistent with the actual behavior and the examples below. APISIX adds `X-Consumer-Custom-Id`, not `Consumer-Custom-Id`, so the prose here may mislead users about which header to read upstream.
--
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-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(key-auth): re-port with Admin API, ADC, and Ingress Controller tabs [apisix]
Posted by "Yilialinn (via GitHub)" <gi...@apache.org>.
Yilialinn commented on code in PR #13241:
URL: https://github.com/apache/apisix/pull/13241#discussion_r3116640386
##########
docs/zh/latest/plugins/key-auth.md:
##########
@@ -32,43 +32,43 @@ description: key-auth 插件支持使用身份验证密钥作为客户端在访
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## 描述
`key-auth` 插件支持使用身份验证密钥作为客户端在访问上游资源之前进行身份验证的机制。
-要使用该插件，您需要在 [Consumers](../terminology/consumer.md) 上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。然后，APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
+要使用该插件，您需要在[消费者](../terminology/consumer.md)上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
-当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Indentifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
+当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Identifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
## 属性
Consumer/Credential 端：
-| 名称 | 类型 | 必选项 | 描述 |
-| ---- | ------ | ------ | ------------------------------------------------------------------------------------------------------------- |
-| key | string | 是 | 不同的 Consumer 应有不同的 `key`，它应当是唯一的。如果多个 Consumer 使用了相同的 `key`，将会出现请求匹配异常。该字段支持使用 [APISIX Secret](../terminology/secret.md) 资源，将值保存在 Secret Manager 中。 |
-
-注意：schema 中还定义了 `encrypt_fields = {"key"}`，这意味着该字段将会被加密存储在 etcd 中。具体参考 [加密存储字段](../plugin-develop.md#加密存储字段)。
+| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
+|------|------|--------|--------|--------|------|
+| key | string | 是 | | | 标识消费者凭证的唯一密钥。密钥在存储到 etcd 之前会使用 AES 加密。您也可以将其存储在环境变量中并使用 `env://` 前缀引用，或存储在 HashiCorp Vault 等密钥管理器中并使用 `secret://` 前缀引用。 |
Review Comment:
Fixed — updated the ZH attributes table with conditional wording: encryption only applies when `apisix.data_encryption.enable_encrypt_fields` is enabled and etcd is used as the config center.
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -385,6 +1086,17 @@ You should see an `HTTP/1.1 200 OK` response. This shows that the key included i
The following example demonstrates how you can attach a Consumer custom ID to authenticated request in the `Consumer-Custom-Id` header, which can be used to implement additional logics as needed.
Review Comment:
Fixed — corrected the prose to use `X-Consumer-Custom-Id` (consistent with the examples below and the actual header APISIX adds).
--
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-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(key-auth): re-port with Admin API, ADC, and Ingress Controller tabs [apisix]
Posted by "Baoyuantop (via GitHub)" <gi...@apache.org>.
Baoyuantop merged PR #13241:
URL: https://github.com/apache/apisix/pull/13241
--
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-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] docs(key-auth): re-port with Admin API, ADC, and Ingress Controller tabs [apisix]
Posted by "Yilialinn (via GitHub)" <gi...@apache.org>.
Yilialinn commented on code in PR #13241:
URL: https://github.com/apache/apisix/pull/13241#discussion_r3116639281
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -32,51 +32,61 @@ description: The key-auth Plugin supports the use of an authentication key as a
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Description
The `key-auth` Plugin supports the use of an authentication key as a mechanism for clients to authenticate themselves before accessing Upstream resources.
-To use the plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on routes or services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
+To use the Plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on Routes or Services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
-When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Indentifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
+When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
## Attributes
For Consumer/Credential:
-| Name | Type | Required | Description |
-|------|--------|-------------|----------------------------|
-| key | string | True | Unique key for a Consumer. This field supports saving the value in Secret Manager using the [APISIX Secret](../terminology/secret.md) resource. |
-
-NOTE: `encrypt_fields = {"key"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See [encrypted storage fields](../plugin-develop.md#encrypted-storage-fields).
+| Name | Type | Required | Default | Valid values | Description |
+|------|------|----------|---------|--------------|-------------|
+| key | string | True | | | A unique key that identifies the Credential for a Consumer. The key is encrypted with AES before being stored in etcd. You can also store it in an environment variable and reference it using the `env://` prefix, or in a secret manager such as HashiCorp Vault's KV secrets engine, and reference it using the `secret://` prefix. |
For Route:
-| Name | Type | Required | Default | Description |
-|--------|--------|-------------|-------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| header | string | False | apikey | The header to get the key from. |
-| query | string | False | apikey | The query string to get the key from. Lower priority than header. |
-| hide_credentials | boolean | False | false | If true, do not pass the header or query string with key to Upstream services. |
-| anonymous_consumer | string | False | false | Anonymous Consumer name. If configured, allow anonymous users to bypass the authentication. |
-| realm | string | False | key | The realm to include in the `WWW-Authenticate` header when authentication fails. |
+| Name | Type | Required | Default | Valid values | Description |
+|------|------|----------|---------|--------------|-------------|
+| header | string | False | apikey | | The header to get the key from. |
+| query | string | False | apikey | | The query string to get the key from. Lower priority than `header`. |
+| hide_credentials | boolean | False | false | | If true, do not pass the header or query string with key to Upstream services. |
+| anonymous_consumer | string | False | | | Anonymous Consumer name. If configured, allow anonymous users to bypass the authentication. |
+| realm | string | False | key | | Realm in the [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc7235#section-4.1) response header returned with a `401 Unauthorized` response due to authentication failure. Available in Apache APISIX version 3.15.0 and later. |
## Examples
The examples below demonstrate how you can work with the `key-auth` Plugin for different scenarios.
:::note
-You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command:
-
```bash
-admin_key=$(yq '.deployment.admin.admin_key[0].key' conf/config.yaml | sed 's/"//g')
+admin_key=$(yq '.deployment.admin.admin_key[0].key' /usr/local/apisix/conf/config.yaml | sed 's/"//g')
Review Comment:
Fixed — confirmed the EN file already uses the relative path `conf/config.yaml`. No change needed.
##########
docs/en/latest/plugins/key-auth.md:
##########
@@ -32,51 +32,61 @@ description: The key-auth Plugin supports the use of an authentication key as a
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## Description
The `key-auth` Plugin supports the use of an authentication key as a mechanism for clients to authenticate themselves before accessing Upstream resources.
-To use the plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on routes or services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
+To use the Plugin, you would configure authentication keys on [Consumers](../terminology/consumer.md) and enable the Plugin on Routes or Services. The key can be included in the request URL query string or request header. APISIX will then verify the key to determine if a request should be allowed or denied to access Upstream resources.
-When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Indentifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
+When a Consumer is successfully authenticated, APISIX adds additional headers, such as `X-Consumer-Username`, `X-Credential-Identifier`, and other Consumer custom headers if configured, to the request, before proxying it to the Upstream service. The Upstream service will be able to differentiate between consumers and implement additional logics as needed. If any of these values is not available, the corresponding header will not be added.
Review Comment:
Fixed — changed 'additional logics' to 'additional logic' (idiomatic English).
##########
docs/zh/latest/plugins/key-auth.md:
##########
@@ -32,43 +32,43 @@ description: key-auth 插件支持使用身份验证密钥作为客户端在访
<link rel="canonical" href="https://docs.api7.ai/hub/key-auth" />
</head>
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
## 描述
`key-auth` 插件支持使用身份验证密钥作为客户端在访问上游资源之前进行身份验证的机制。
-要使用该插件，您需要在 [Consumers](../terminology/consumer.md) 上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。然后，APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
+要使用该插件，您需要在[消费者](../terminology/consumer.md)上配置身份验证密钥，并在路由或服务上启用该插件。密钥可以包含在请求 URL 查询字符串或请求标头中。APISIX 将验证密钥以确定是否应允许或拒绝请求访问上游资源。
-当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Indentifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
+当消费者成功通过身份验证后，APISIX 会在将请求代理到上游服务之前向请求添加其他标头，例如 `X-Consumer-Username`、`X-Credential-Identifier` 和其他消费者自定义标头（如果已配置）。上游服务将能够区分消费者并根据需要实现其他逻辑。如果这些值中的任何一个不可用，则不会添加相应的标头。
## 属性
Consumer/Credential 端：
-| 名称 | 类型 | 必选项 | 描述 |
-| ---- | ------ | ------ | ------------------------------------------------------------------------------------------------------------- |
-| key | string | 是 | 不同的 Consumer 应有不同的 `key`，它应当是唯一的。如果多个 Consumer 使用了相同的 `key`，将会出现请求匹配异常。该字段支持使用 [APISIX Secret](../terminology/secret.md) 资源，将值保存在 Secret Manager 中。 |
-
-注意：schema 中还定义了 `encrypt_fields = {"key"}`，这意味着该字段将会被加密存储在 etcd 中。具体参考 [加密存储字段](../plugin-develop.md#加密存储字段)。
+| 名称 | 类型 | 必选项 | 默认值 | 有效值 | 描述 |
+|------|------|--------|--------|--------|------|
+| key | string | 是 | | | 标识消费者凭证的唯一密钥。密钥在存储到 etcd 之前会使用 AES 加密。您也可以将其存储在环境变量中并使用 `env://` 前缀引用，或存储在 HashiCorp Vault 等密钥管理器中并使用 `secret://` 前缀引用。 |
Review Comment:
Fixed — updated the ZH attributes table to use `$env://` and `$secret://` prefixes (with the leading `$`).
--
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-unsubscribe@apisix.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org