Question

我们正在完全重写我们的主API代理配置，我们发现我们的新配置（或者我们现有的配置）与API密钥的验证方式有关。我们当前的API使用策略 GetOAuthV1Info

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GetOAuthV1Info enabled="true" continueOnError="false" async="false" name="APIKey-Validate">
<DisplayName>APIKey-Validate</DisplayName>
    <FaultRules/>
    <Properties/>
    <AppKey ref="request.queryparam.apikey"></AppKey>
</GetOAuthV1Info>

我们的新配置使用策略 VerifyAPIKey

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-Api-Key">
    <DisplayName>Verify API Key</DisplayName>
    <APIKey ref="request.queryparam.apikey"/>
</VerifyAPIKey>

从表面上看，这两项政策似乎都运作良好。但是，在将新配置部署到我们的测试环境后，某些API密钥失败并出现401 Unauthorized错误。深入研究这些密钥后，我们发现它们被分配给无法访问 test 环境的产品。看来 GetOAuthV1Info 步骤没有验证环境..？ GetOAuthV1Info 的文档没有帮助，因为它根本没有谈论APIKeys（http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-10a）。

修复此特定问题非常简单，因为我们只需要允许其他产品访问测试环境。但是，这让我想知道这两个政策之间的其他差异是什么？我现在非常紧张地对这些API代理进行任何更改，因为我不知道还有什么会破坏，或者会出现哪些其他无法预料的问题。

这是 GetOAuthV1Info 政策的已知限制吗？为什么这甚至可以工作？这两个政策之间的其他差异可能会在以后引起我的兴趣？

Answer 1

我所知道的唯一区别是，在VerifyAPIKey策略中，变量名称的分配方式不同（它将策略类型和名称附加到类似verifyapikey.verify_apikey-1.apiproduct.developer.quota的字体。限制例如）。

VerifyAPIKey和OAuth 1都支持环境限制 - 当我在无效环境中使用APIKey测试GetOAuthV1时出现此错误：

 OAuth Failure : Invalid API call as no apiproduct match found

请记住，大多数项目的约定似乎是OAuth2流程或VerifyAPI，因此有关OAuth1策略的信息较少。

使用GetOAuthV1Info和VerifyAPIKey验证APIKeys的差异

1 个答案: