python接口自动化踩坑小记

在我们用脚本发起接口请求时，除了会将鉴权加入headers中，有时候还需要加入User-Agent参数模拟浏览器请求，但是源站的请求需要我们提供“安全上下文”时，这些常规的headers参数并不能实现我们想要的操作，除非源站的信息敏感或不必要的。

在项目中，如果我用接口请求一个渠道发起入金请求，请求headers中加入了鉴权和模拟浏览器行为，但是接口响应了一个这样的信息：

{'code': 2001, 'message': 'DATA_WRITE_FAILED', 'data': '非法来源'}

同样的请求头，在请求项目的其他接口如发送邮件，更改密码等都能成功发起请求操作发送邮件或是改密成功，为什么这个入金的接口却不行呢？

这时候主角就该登场了：请求标头：Origin参数

Origin

请求标头 Origin 表示了请求的来源（协议、主机、端口）。例如，如果一个用户代理需要请求一个页面中包含的资源，或者执行脚本中的 HTTP 请求（fetch），那么该页面的来源（origin）就可能被包含在这次请求中。

常用语法：

Origin: null 请求的来源是“隐私敏感”的，或者是 HTML 规范定义的不透明来源
Origin: <scheme>://<hostname> 
Origin: <scheme>://<hostname>:<port> 

<scheme>：请求所使用的协议，通常是 HTTP 协议或者它的安全版本（HTTPS 协议）。

<hostname>：源站的域名或 IP 地址。

<port> : 服务器正在监听的端口号。缺省为服务的默认端口（对于 HTTP 请求而言，默认端口为 80）

Origin 标头与referer标头类似，但前者不会暴露 URL 的 path 部分，而且其可以为 null 值。其用于为源站的请求提供“安全上下文”，除非源站的信息敏感或不必要的。

描述

Origin 标头与 Referer 标头类似，但前者不会暴露 URL 的 path 部分，而且其可以为 null 值。其用于为源站的请求提供“安全上下文”，除非源站的信息敏感或不必要的。

从广义上讲，用户代理会在以下情况中添加 Origin 请求标头：

• 跨源请求。
• 除 GET和  HEAD 以外的同源请求（即它会被添加到同源的POST 、OPTIONS、PUT​​​​​​​、PATCH和DELETE 请求中）。

除上述规则外，还有一些特殊情况。例如，在 ​​​​​​​no-cors 模式下的跨源 GET或 HEAD请求不会发送 Origin 标头。

Origin 标头在以下情况中（不完整）会被设置为 null：

• 请求来源的协议不是 http、https、ftp、ws、wss 或 gopher 中的任意一个（如：blob、file 和 data）。
• 跨源的图像或媒体，包括：<img>、<video> 和 <audio> 元素。
• 属于以下几种文档类型的：使用 createDocument() 创建的、通过 data: URL 生成的或没有创建者的浏览上下文的。
• 跨源重定向。
• 没有为 sandbox 属性设置 allow-same-origin 值的 iframe。
• 响应（response）是网络错误。

所以在发起入金请求时，没有在请求标头中加入来源，返回 '非法来源' 信息。抓包的请求标头中：

 在headers中添加Origin 参数，请求成功：