HTTP HEADER 之 ORIGIN 深入理解

背景

最近在做一个服务集成的项目，需要将一个第三方的日志服务系统直接接入我们现有的日志系统中，第三方服务支持Bearer授权访问，故 最后解决方案是前端直接调用第三方服务获取数据。但是遇到了鉴权的问题, 最后获知是Origin导致的

Origin 的来源和作用

经查询资料, Origin是Referer头的升级版, 常用于CORS或者非GET、HEAD请求(MDN 的说法有误，不是只有 POST)相关的服务端身份检验

个人觉得，这个 Origin 头绝大部分都用于 CORS

FAQ

浏览器端Origin无法手动设置

• Origin头是浏览器保护字段，类似的有 Referer、Host、Content-Length、Keep-alive等，但是可以通过 nginx 代理修改。浏览器根据约定自动附加

浏览器附加Origin头的规则

• 根据fetch说明, 只有当请求为跨域请求或者非get,head请求时都会自动附加。不可被编程，不可被编辑。get,head请求由于兼容性，故无法实现

非 CORS 情况下, Origin字段框架使用情况

• 据我了解, 绝大部分框架都没有使用 Origin 字段, 我所待的几个公司也从未根据此值来判断

所有符合规则的资源都会包含 Origin 头?

• 不是。例如跨域图片不会包含 Origin 头, 更多资源请查看

Hack CORS

浏览器执行 CORS(跨域请求)时都会发送一个options请求，获取服务端是否允许跨域的参数。这是为了安全性考虑的。有些情况我们无法控制服务端的行为，故只能想办法绕过验证。

• 本地开发: 使用node-http-proxy代理服务请求

• 生产/本地开发: 使用 nginx 代理服务, 例如

location ~ ^\/(scholar_complete)\/* {
    proxy_pass https://scholar.google.com/;
}

这会将所有/scholar_complete开头的请求转发到 Google Scholar(谷歌学术)。

• jsonp是一种较老的方式, 现在基本不考虑了。

Reference

• Bearer
• CROS
• MDN ORIGIN
• origin-header
• When do browsers send the Origin header? When do browsers set the origin to null?