查看 Apigee Edge 說明文件。
前往
Apigee X說明文件。 資訊

結果
「驗證 API 金鑰」政策可讓您在執行階段強制執行 API 金鑰驗證, 如果您的應用程式具有已核准的 API 金鑰,就會存取您的 API。這項政策可確保 API 金鑰有效,且 使用與 API 相關聯的特定資源並未撤銷,且已獲準使用 很少直接解答該如何打造產品
範例
查詢參數中的鍵
<VerifyAPIKey name="APIKeyVerifier"> <APIKey ref="request.queryparam.apikey" /> </VerifyAPIKey>
在此範例中,政策預期在名為
request.queryparam.apikey
。request.queryparam.{name}
變數
是標準的 Edge 流程變數,用來填入所傳遞的查詢參數值
。
以下 curl
指令會在查詢參數中傳遞 API 金鑰:
curl http://myorg-test.apigee.net/mocktarget?apikey=IEYRtW2cb7A5Gs54A1wKElECBL65GVls
標頭中的索引鍵
<VerifyAPIKey name="APIKeyVerifier"> <APIKey ref="request.header.x-apikey" /> </VerifyAPIKey>
在此範例中,政策預期在名為
request.header.x-apikey
。request.header.{name}
變數
是標準的 Edge 流程變數,用來填入
。
下列 cURL 說明如何透過標頭傳送 API 金鑰:
curl "http://myorg-test.apigee.net/mocktarget" -H "x-apikey:IEYRtW2cb7A5Gs54A1wKElECBL65GVls"
變數中的鍵
<VerifyAPIKey name="APIKeyVerifier"> <APIKey ref="requestAPIKey.key"/> </VerifyAPIKey>
這項政策可參照任何內含鍵的變數。本例中的政策 從名為 requestAPIKey.key 的變數擷取 API 金鑰。
變數的填入方式由您決定。舉例來說,您可以使用 要從查詢參數填入 requestAPIKey.key 的變數政策 名稱為 myKey,如圖所示 如下:
<ExtractVariables async="false" continueOnError="false" enabled="true" name="SetAPIKeyVar"> <Source>request</Source> <QueryParam name="myKey"> <Pattern ignoreCase="true">{key}</Pattern> </QueryParam> <VariablePrefix>requestAPIKey</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
存取權政策流程變數
<AssignMessage async="false" continueOnError="false" enabled="true" name="accessverifyvars"> <AssignVariable> <Name>devFirstName</Name> <Ref>verifyapikey.verify-api-key.developer.firstName</Ref> <Value>ErrorOnCopy</Value> </AssignVariable> <AssignVariable> <Name>devLastName</Name> <Ref>verifyapikey.verify-api-key.developer.lastName</Ref> <Value>ErrorOnCopy</Value> </AssignVariable> <AssignVariable> <Name>devEmail</Name> <Ref>verifyapikey.verify-api-key.developer.email</Ref> <Value>ErrorOnCopy</Value> </AssignVariable> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
執行 Verify API 金鑰時,Edge 會自動填入一組流程變數 政策。您可以使用這些變數存取應用程式等資訊 的名稱、應用程式 ID,以及註冊應用程式的開發人員或公司相關資訊。在 上述範例使用「指派訊息」政策來存取開發人員的名字 和電子郵件地址。
這些變數的前置字元如下:
verifyapikey.{policy_name}
在這個範例中,Verify API 金鑰政策名稱為「verify-api-key」。因此,您應該參照
方法是存取
變數 verifyapikey.verify-api-key.developer.firstName.
瞭解 Edge
關於「驗證 API 金鑰」政策
當開發人員在 Edge 上註冊應用程式時,Edge 會自動產生用戶端金鑰, 密鑰配對。您可以在 Edge UI 中查看或存取應用程式的用戶端金鑰和密鑰組
在應用程式註冊時,開發人員會選取一或多項 API 產品來 與應用程式建立關聯,其中 API 產品是一組 資源 可透過 API Proxy 存取接著,開發人員會將 API 金鑰 (用戶端金鑰) 做為 應用程式相關 API 產品中 API 的每個要求。詳情請參閱「發布總覽」。
API 金鑰可做為驗證權杖,也可用來取得 OAuth 存取權 符記在 OAuth 中,API 金鑰稱為「用戶端 ID」。這些名稱可以交替使用。 詳情請參閱 OAuth 首頁。
執行 Verify API 金鑰政策時,Edge 會自動填入一組流程變數。 請參閱流程 變數。
元素參照
以下為這項政策可設定的元素和屬性:
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key-1"> <DisplayName>Custom label used in UI</DisplayName> <APIKey ref="variable_containing_api_key"/> </VerifyAPIKey>
<VerifyAPIKey>屬性
下例顯示 <VerifyAPIKey>
標記中的屬性:
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key-1">
下表說明所有政策父項元素的共同屬性:
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
name |
政策的內部名稱。 視需要使用 |
不適用 | 必填 |
continueOnError |
如果設為「 如果設為 |
false | 選用 |
enabled |
如要強制執行政策,請設為 設為 |
true | 選用 |
async |
此屬性已淘汰。 |
false | 已淘汰 |
<DisplayName>元素
除 name
屬性外,一併使用
管理 UI Proxy 編輯器,使用不同的自然語言名稱。
<DisplayName>Policy Display Name</DisplayName>
預設 |
不適用 如果省略這個元素,政策的 |
---|---|
存在必要性 | 選用 |
類型 | 字串 |
<APIKey>元素
此元素會指定包含 API 金鑰的流程變數。一般來說,用戶端會傳送 API 金鑰
查詢參數、HTTP 標頭或表單參數中舉例來說,如果金鑰是在標頭中傳送
名為 x-apikey
的鍵位於變數中:request.header.x-apikey
預設 | 不適用 |
---|---|
存在必要性 | 必填 |
類型 | 字串 |
屬性
下表說明 <APIKey>
元素的屬性
屬性 | 說明 | 預設 | 存在必要性 |
---|---|---|---|
參考資料 |
這是對包含 API 金鑰的變數的參照。只能有一個位置 每個政策。 |
不適用 | 必填 |
範例
在這些範例中,金鑰會透過參數和名為 x-apikey
的標頭傳遞。
做為查詢參數:
<VerifyAPIKey name="APIKeyVerifier"> <APIKey ref="request.queryparam.x-apikey"/> </VerifyAPIKey>
做為 HTTP 標頭:
<VerifyAPIKey name="APIKeyVerifier"> <APIKey ref="request.header.x-apikey"/> </VerifyAPIKey>
做為 HTTP 表單參數:
<VerifyAPIKey name="APIKeyVerifier"> <APIKey ref="request.formparam.x-apikey"/> </VerifyAPIKey>
結構定義
流程變數
對有效的 API 金鑰強制執行 Verify API 金鑰政策時,Edge 會填入一組流程 變數。這些變數可供在流程中稍後執行的政策或程式碼使用, 通常用於根據 API 金鑰的屬性,例如應用程式名稱、 用來授權 API 金鑰或自訂屬性的 API 產品。
這項政策可填入幾種不同類型的流程變數,包括:
- 一般
- 應用程式
- 開發人員
- 公司
- Analytics
每種流程變數都有不同的前置字元。所有變數均為純量,除了這些項目 並明確表示為陣列
一般流程變數
下表列出「Verify API 金鑰」政策填入的一般流程變數。 這些變數的前置字元如下:
verifyapikey.{policy_name}
例如:verifyapikey.{policy_name}.client_id
可用的變數包括:
變數 | 說明 |
---|---|
client_id |
要求應用程式提供的用戶端金鑰 (又稱為 API 金鑰或應用程式金鑰)。 |
client_secret |
與用戶端金鑰相關聯的用戶端密鑰。 |
redirection_uris |
要求中的所有重新導向 URI。 |
developer.app.id |
發出要求的開發人員應用程式 ID。 |
developer.app.name |
發出要求的開發人員應用程式名稱。 |
developer.id |
已註冊為提出要求應用程式擁有者的開發人員 ID。 |
developer.{custom_attrib_name} |
衍生自應用程式金鑰設定檔的任何自訂屬性。 |
DisplayName |
政策的 <DisplayName> 值屬性。 |
failed |
設為「true」API 金鑰驗證失敗時。 |
{custom_app_attrib} |
衍生自應用程式設定檔的任何自訂屬性。指定自訂的 屬性。 |
apiproduct.name* |
用於驗證要求的 API 產品名稱。 |
apiproduct.{custom_attrib_name}* |
由 API 產品設定檔衍生的任何自訂屬性。 |
apiproduct.developer.quota.limit* |
API 產品設定的配額限制 (如有)。 |
apiproduct.developer.quota.interval* |
API 產品中設定的配額間隔 (如有)。 |
apiproduct.developer.quota.timeunit* |
API 產品上設定的配額時間單位 (如果有的話)。 |
* 如果 API 產品,系統會自動填入 API 產品變數
具備有效環境、Proxy 和資源 (衍生自
proxy.pathsuffix )。如需設定 API 產品的操作說明,請參閱
使用邊緣
Management API 發布 API |
應用程式流程變數
以下流程變數會由政策填入,內含應用程式相關資訊。 這些變數的前置字元如下:
verifyapikey.{policy_name}.app
。
例如:
verifyapikey.{policy_name}.app.name
可用的變數包括:
變數 | 說明 |
---|---|
name |
應用程式名稱。 |
id |
應用程式的 ID。 |
accessType |
Apigee 未使用。 |
callbackUrl |
應用程式的回呼網址。通常僅適用於 OAuth。 |
DisplayName |
應用程式的顯示名稱。 |
status |
應用程式狀態,例如「已核准」或「已撤銷」 |
apiproducts |
包含與應用程式相關聯的 API 產品清單的陣列。 |
appFamily |
包含該應用程式的任何應用程式系列 (或稱「預設」)。 |
appParentStatus |
應用程式的父項狀態,例如「使用中」或「無效」 |
appType |
應用程式類型,如「Company」或「開發人員」 |
appParentId |
父項應用程式的 ID。 |
created_at |
建立應用程式的日期/時間戳記。 |
created_by |
開發應用程式的開發人員電子郵件地址。 |
last_modified_at |
應用程式上次更新的日期/時間戳記。 |
last_modified_by |
上次更新應用程式的開發人員電子郵件地址。 |
{app_custom_attributes} |
任何自訂應用程式屬性。指定自訂屬性的名稱。 |
開發人員流程變數
以下流程變數 (包含開發人員相關資訊) 會填入 政策。這些變數的前置字元如下:
verifyapikey.{policy_name}.developer
例如:
verifyapikey.{policy_name}.developer.id
可用的變數包括:
變數 | 說明 |
---|---|
id |
傳回 {org_name}@@{developer_id} |
userName |
開發人員的使用者名稱。 |
firstName |
開發人員的名字。 |
lastName |
開發人員的姓氏。 |
email |
開發人員的電子郵件地址。 |
status |
開發人員的狀態,例如有效、已停用或 login_lock。 |
apps |
與開發人員相關的一系列應用程式。 |
created_at |
開發人員建立的日期/時間戳記。 |
created_by |
開發人員建立使用者的電子郵件地址。 |
last_modified_at |
開發人員上次修改的日期/時間戳記。 |
last_modified_by |
已修改開發人員的使用者電子郵件地址。 |
{developer_custom_attributes} |
任何自訂的開發人員屬性。指定自訂屬性的名稱。 |
Company |
與開發人員相關聯的公司名稱 (如果有的話)。 |
公司流程變數
以下包含公司相關資訊的流程變數是由 政策。這些變數的前置字元如下:
verifyapikey.{policy_name}.company
例如:
verifyapikey.{policy_name}.company.name
可用的變數包括:
變數 | 說明 |
---|---|
name |
公司名稱。 |
displayName |
公司的顯示名稱。 |
id |
公司 ID。 |
apps |
包含公司應用程式清單的陣列。 |
appOwnerStatus |
應用程式擁有者的狀態,例如「有效」、「已停用」或「登入鎖定」。
|
created_at |
公司建立的日期/時間戳記。 |
created_by |
公司建立使用者的電子郵件地址。 |
last_modified_at |
上次修改公司的日期/時間戳記。 |
last_modified_by |
上次修改公司的使用者電子郵件地址。 |
{company_custom_attributes} |
任何自訂公司屬性。指定自訂屬性的名稱。 |
Analytics 變數
驗證 API 金鑰政策時,Analytics 會自動填入下列變數 強制針對有效 API 金鑰強制執行這些變數只會由 Verify API 金鑰填入 政策和 OAuth 政策
您可以使用變數和值建立 Analytics 報表,進而取得 瞭解開發人員和應用程式的消費模式
- apiproduct.name
- developer.app.name
- client_id
- developer.id
錯誤參考資料
This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.
Runtime errors
These errors can occur when the policy executes.
Fault code | HTTP status | Cause |
---|---|---|
keymanagement.service.CompanyStatusNotActive |
401 | The Company associated with the Developer App that has the API key you are using has an inactive status. When a Company's status is set to inactive, you cannot access the developers or apps associated with that Company. An org admin can change a Company's status using the management API. See Set the Status of a Company. |
keymanagement.service.DeveloperStatusNotActive |
401 |
The developer who created the Developer App that has the API key you are using has an inactive status. When an App Developer's status is set to inactive, any Developer Apps created by that developer are deactivated. An admin user with appropriate permissions (such as Organization Administrator) can change a developer's status in the following ways:
|
keymanagement.service.invalid_client-app_not_approved |
401 | The Developer App associated with the API key is revoked. A revoked app cannot access any API products and cannot invoke any API managed by Apigee Edge. An org admin can change the status of a Developer App using the management API. See Approve or Revoke Developer App. |
oauth.v2.FailedToResolveAPIKey |
401 | The policy expects to find the API key in a variable that is specified in the policy's <APIKey> element. This error arises when the expected variable does not exist (it cannot be resolved). |
oauth.v2.InvalidApiKey |
401 | An API key was received by Edge, but it is invalid. When Edge looks up the key in its database, it must exactly match the on that was sent in the request. If the API worked previously, make sure the key was not regenerated. If the key was regenerated, you will see this error if you try to use the old key. For details, see Register apps and manage API keys. |
oauth.v2.InvalidApiKeyForGivenResource |
401 | An API key was received by Edge, and it is valid; however, it does not match an approved key in the Developer App associated with your API proxy through a Product. |
Deployment errors
These errors can occur when you deploy a proxy containing this policy.
Error name | Cause |
---|---|
SpecifyValueOrRefApiKey |
The <APIKey> element does not have a value or key specified. |
Fault variables
These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.
Variables | Where | Example |
---|---|---|
fault.name="fault_name" |
fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. | fault.name Matches "FailedToResolveAPIKey" |
oauthV2.policy_name.failed |
policy_name is the user-specified name of the policy that threw the fault. | oauthV2.VK-VerifyAPIKey.failed = true |
Example error responses
{ "fault":{ "faultstring":"Invalid ApiKey", "detail":{ "errorcode":"oauth.v2.InvalidApiKey" } } }
{ "fault":{ "detail":{ "errorcode":"keymanagement.service.DeveloperStatusNotActive" }, "faultstring":"Developer Status is not Active" } }
Example fault rule
<FaultRule name="FailedToResolveAPIKey"> <Step> <Name>AM-FailedToResolveAPIKey</Name> </Step> <Condition>(fault.name Matches "FailedToResolveAPIKey") </Condition> </FaultRule>