什么是API密钥？

Scrapeless Web Unlocker通过在x-api-token头部发送的Scrapeless API密钥来验证文档化的API请求。

API密钥是由服务发出的值，因此软件在发出请求时可以识别自己。它通常属于帐户、项目或应用程序，而不是人类用户会话。服务器检查提供的值并应用其自己的访问和使用规则。密钥格式、头部名称、范围控制和到期行为是特定于提供者的。客户端应从当前API文档中了解这些规则，而不是假设每个密钥都像承载令牌那样工作。

对于Web数据应用程序，这一区别是实用的。请求可能到达正确的端点，但由于未提供密钥、密钥在错误的字段中发送或帐户没有访问该产品的权限而失败。相反，成功验证的密钥并不证明请求的URL或有效负载是有效的。本指南将密钥视为受控请求的一部分，并跟踪其从创建到撤销的生命周期。

密钥识别的内容及其未识别的内容

提供者可以发放密钥以识别调用者、计量使用、执行配额并将请求与帐户或项目关联。一些系统还允许通过环境、操作或网络来源来限制密钥。除非提供者实际提供这些限制，否则不应假设任何这些限制。密钥是凭证；提供者的授权策略决定该凭证在请求时可以执行什么。

密钥与用户密码不同。它通常在没有交互式登录的情况下授予机器访问权限，并且多个服务可能依赖于它。它也不一定是OAuth访问令牌。 OAuth承载令牌规范 描述了一种展示方案；许多API密钥系统使用自定义头部。将每个秘密视为承载值可能会破坏身份验证或将其放置在提供者从未打算的位置。

Scrapeless API密钥指南 表示Web Unlocker REST请求在不带Bearer前缀的情况下将原始密钥发送到x-api-token。相同的指导解释了其他Scrapeless接口可以使用不同的连接方法。在将凭证在REST客户端、浏览器连接、代理配置或SDK之间移动之前，请阅读所选择的产品指南。

API密钥在HTTP请求中的位置

服务合同决定凭证是在头部、其他传输字段，还是特定连接参数中。HTTP头部对于服务器到服务器的API很常见，因为它们将凭证与资源URL分开。 HTTP字段模型 解释请求元数据是如何随消息传递的。头部仍然对客户端、其控制下的代理和如果这些系统记录的话服务器日志可见；头部不能替代TLS或日志编辑。

除非提供者明确要求，否则避免将长期密钥放入URL中。URL可能出现在浏览器历史记录、分析、引荐流、反向代理日志和粘贴的屏幕截图中。即使是正确的头部也可能泄露，如果详细的HTTP跟踪打印完整请求。共享诊断之前，请在共享的x-api-token和任何嵌入令牌的连接URL之前进行编辑。存储请求ID或安全前缀以供支持，而不是完整的凭证。

应用程序在发送请求之前应拒绝意外的空密钥。在服务器进程中，从部署环境或秘密管理器读取秘密，如果缺失则启动失败。本地开发Shell可以为一次会话加载一个值，但这并不意味着密钥在Shell历史记录或提交的配置文件中是安全的。保留示例作为占位符，并仅在私有环境中测试实际值。

开发和部署中的安全存储

在开发期间，使用一个不包含在版本控制中的环境变量或本地秘密文件。一个.env文件只是存储；除非加载器或应用程序代码读取它，否则过程不会读取它。共享示例文件应包含空值或明显的占位符。 OWASP硬编码凭证指南 解释了为什么嵌入源代码中的秘密在分发后难以控制。

在生产中，将密钥放入平台的秘密存储中，仅授予需要它的服务读取访问权限。在运行时注入，而不是将其烘焙到映像或前端捆绑中。审核谁可以更改秘密，以及哪些部署使用它。浏览器端JavaScript应用程序无法将长期密钥保密于运行该浏览器的人；当密钥授予帐户级访问权限时，请使用受信任的后端。

也要保护相邻的表面。CI输出、错误跟踪、请求跟踪、笔记本单元、支持票据和屏幕录制都可能携带凭证，即使存储库不包含。为已知的头部名称和密钥模式配置自动编辑，但检查代表性日志以确认过滤器有效。限制之前捕获秘密的日志的保留，并在撤销后删除暴露的副本。

如何使用密钥而不误读错误

请求有几个验证阶段。服务器检查传输和语法，识别凭证，评估访问，检查特定产品的输入，最终返回结果或错误。身份验证失败表明密钥缺失、格式错误、过期或通过错误的方法发送。即使密钥被识别，授权或余额失败也可能发生。无效的有效载荷是一个单独的问题。仅更改文档中提到的错误所涉及的层。

Scrapeless 将获取用户信息请求记录为无需启动抓取工作即可验证密钥身份验证的一种方式。在那里成功的身份验证证明了密钥在该操作中有效；它并未建立对每个产品的访问。一个小的，有文档记录的 Web Unlocker 请求 则可以测试特定产品的路径。检查响应主体以及 HTTP 状态，并且永远不要发布通过验证调用返回的账户信息。

该 Web Unlocker 产品页面 描述了基于 URL 的公共网页检索。如果获取的响应缺少预期内容，避免仅仅因为相同的调用使用了密钥而将密钥视为可能的原因。确认目标 URL、重定向、渲染需求、输出类型和源页面的身份。凭证验证和内容验证回答不同的问题。

轮换、曝光和撤销

计划轮换是阶段性部署更改。清点使用旧密钥的服务，通过提供商可用的控件配置替代品，更新每个秘密存储，仅在启动时重新启动读取秘密的进程，并验证代表性操作。一旦新密钥经过验证，使旧密钥失效。记录切换的所有者和时间，以便稍后的故障可以追溯到更改而不是猜测。

暴露的密钥首先需要隔离。通过提供商可用的控件或支持渠道使其失效，即使这会中断工作，然后发布替代品并审查最近的使用情况。删除存储库提交或编辑屏幕截图并不会使复制的密钥失效。保留足够的事件证据以了解曝光发生的位置，但在调查期间避免将秘密复制到新的票证中。

范围和过期减少爆炸半径，当提供商提供它们时，但它们并不能消除安全存储的需求。狭义范围的密钥仍然可以在其范围内泄露数据或产生费用。在账户模型支持的地方，将开发凭证与生产凭证分开。如果一个密钥用于几个无关的工作，轮换变得更加困难，因为每个消费者必须一起移动；在紧急情况下之前规划该依赖关系。

在 API 密钥和委托访问之间选择

API 密钥非常适合使用自己账户的后端服务，特别是当提供商提供清晰的限制和撤销时。它们并不是授予无关的第三方应用程序广泛访问用户账户的好方法。委托授权协议可以代表用户授予有限的访问权限，并提供独立的令牌生命周期。正确的选择取决于信任关系，而不是凭证在示例中看起来更短。

对于客户端集成，写下谁拥有账户，秘密存储在哪里，它能做什么，使用情况如何监控，以及如何撤销它。如果移动或浏览器应用程序必须调用提供商，请考虑一个从受信环境中验证最终用户并随后发出提供商请求的后端代理。该后端需要自己的授权检查，因此它不能成为开放的中继。

相关的 Python API 调用指南 显示周围的 HTTP 机制。将其传输理念与可能变化的特定于提供商的身份验证细节分开。对于 Scrapeless，目前的密钥处理文档仍然是确切的头部和验证表面的权威。

结论

API 密钥根据提供商的访问政策识别调用者。其安全使用取决于确切的请求方法、受控存储、编辑过的诊断和经过测试的替代过程。通过文档化的操作验证密钥，然后单独验证产品访问和响应内容。