关于referrer
在接入微信 h5 支付遇到了 referrer 为空的问题之后，也看过很多博主整理的相关文档，然后还是自己简单整理一下，加深一下理解。
一、简单介绍
枯燥的概念
Referer 首部包含了当前请求页面的来源页面的地址，即表示当前页面是通过此来源页面里的链接进入的。服务端一般使用 Referer 首部识别访问来源，可能会以此进行统计分析、日志记录以及缓存优化等
比方说
在一个不火热的旅游景点（很优美没有过度开发的那种）开了个客栈，有一个很无聊的老板，当有游客入住的时候，都会问
场景一：
- 无聊老板: 我是广东佛山那边的，你是哪边的？
- 游客：我是肇庆的。
- 无聊老板：我们是一个省份的，哈哈哈。
场景二：
- 无聊老板: 我是广东佛山那边的，你是哪边的？
- 游客：我是从东土大唐而来【心里 os，广东人吃胡建人】。
- 无聊老板：哦哦【心里 os，二般游客】
二、正文
referrer 是否发送，在 chrome 默认的行为里面是会带的（除了是新标签直接访问页面），这样会带来一个问题
- 可能会暴露用户的浏览历史
那什么情况下不会带这个信息？
- 安全降级，例如 https -> http
- 协议为 file，例如 file://xxx.html
- 协议为 data，例如
<img src="data:" /> - 主动配置
怎么主动配置是否带 referer？
配置 referrer-policty
| 属性值 | 描述 |
|---|---|
| no-referrer | 不发送 referrer |
| no-referrer-when-downgrage | 安全等级降级的时候不发，例如 https->http |
| origin | 只发送”源” |
| origin-when-cross-origin | 非同源只发送”源”，同源访问发送具体的 url |
| same-origin | 同源访问发送具体 url |
| strict-origin | 同等安全等级的页面访问才发 url |
| strict-origin-when-cross-origin | 同等安全等级且同源的情况下才发送 url |
| unsafe-url | 无论是同源请求还是非同源请求都发送完整的 url |
配置的地方
- 通过设置标签，例如,a,area,img,iframe,script,link
1 | 例如： |
- 配置 meta
1 | <meta name="referrer" conent="origin" /> 这个时候，referer只会显示origin |
有什么应用场景？
1.匿名
有时候匿名者不希望被知道自己的身份，会主动从 http 报文中删除 ua,ip,referer 来保证私密性跟匿名性，
2.根据 referer 去做对应的处理
微信 h5 支付，在调起支付的时候，就会去验证 referer 是否是配置的安全域名
b 站点用到很多 a 站点的服务，两个站点的 host 又是一致的，当有一天两个站点的服务要独立的时候，想要去整理 b 站点具体依赖到 a 站点哪些服务是很麻烦的，这个时候直接通过 referer 去区分就可以直接得知了。
3.防御 CSRF（跨站请求伪造）
描述：跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行
解决方式：检查 http headers referer 字段是否同源或者在白名单里面。
- 反爬虫,no referrer 或者 非指定地址的 referrer 访问图片资源的时候，统一按异常处理。
注意：看到上面其实有 referer，也有 referrer，referer 是错误的写法，正确的写法是 referrer。http header 里面还是 referer 属性，没有修正。其他的才修正了写法。