在我们用脚本发起接口请求时,除了会将鉴权加入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
参数,请求成功: