Cloudflare 错误 1010 在应用程序接口（API）的身份验证层看到请求之前，就拒绝了 Python 的默认用户代理（User-Agent）。如何将其与真正的 401 错误区分开来，以及修复该问题的四个请求头。
最初发布于 dhseadev.online。
我因为一个从未出错的凭证浪费了一个小时。
任务很小：通过供应商的代表性状态传输（REST）应用程序接口（API）搭建一个只读的模型上下文协议服务器，这样助手就可以读取工作记录，而无需我将电子表格导出文件粘贴到聊天窗口中。供应商使用客户自己的应用程序接口密钥通过超文本传输协议基本认证进行身份验证。只需两行 urllib 代码。午餐前就能搞定。
每个请求返回的结果都一样：
HTTP/1.1 403 禁止访问
错误代码：1010
简而言之
Cloudflare 错误 1010 并非身份验证失败。 它是在 Cloudflare 边缘节点发出的浏览器签名禁令——“本网站所有者已根据您的浏览器签名禁止您的访问”——而 Python 默认的 User-Agent 足以触发此禁令。
请求从未到达应用程序接口自身的身份验证层。这就是为什么你尝试的每个凭证都以相同的方式失败。解决方法是添加四个请求头，而不是更换一个新的密钥。
如果这解决了你下午的问题，你可以停止阅读了。剩下的部分是我觉得更有用的内容：如何仅从失败现象中判断出，你并没有在与你认为正在通信的对象进行交互。
为什么正确的密钥仍然返回 403
我做了每个人都会做的事。将密钥作为用户名，密码留空；将密钥作为持有者令牌；将密钥放在 X-API-Key 请求头中。重新检查了 Base64 填充。重新生成了密钥。再次尝试。
六种变体。每一个都返回了 403 和 error code: 1010。
这看起来像是权限问题。这时你开始起草一封电子邮件给支持团队，询问你的密钥缺少哪个作用域，时间就这样流逝了。
关键在于失败是完全相同的
身份验证层的作用是区分差异。这是其全部职责所在。
格式错误的请求头不应以与携带已撤销密钥的有效请求头相同的方式失败，后者也不应以与有效密钥访问其无法看到的端点相同的方式失败。这是三种不同的情况，一个合格的身份验证层会对它们给出三种不同的回应。
当六个实质不同的请求产生字节级完全相同的响应时，说明没有任何程序在读取这些字节。答案来自挡在你试图通信的对象前面的某个东西。
这一规律不仅适用于 Cloudflare，这也是值得记住的部分：在不同输入下出现完全相同的失败输出，意味着输入未被检查。 改变一些本应影响结果的因素。如果错误信息没有变化，说明你在调试错误的层级。
在这种情况下，挡在前面的东西是 Cloudflare 的浏览器完整性检查。Python 标准库将自己标识为 User-Agent: Python-urllib/3.x，而用户代理请求头是边缘节点进行过滤成本最低的指纹特征。仅凭这个字符串，我发送的每个请求都被丢弃了
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
