Referer丢失的示例分析
这篇文章主要介绍Referer丢失的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
10年积累的网站设计、网站建设经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先网站制作后付款的网站建设流程,更有来凤免费网站建设让你可以放心的选择与我们合作。
Referer 是什么
HTTP Referer是 HTTP
请求 header
头信息的一部分 当浏览器向web服务器发送请求的时候,一般会带上Referer
告诉服务器我是从哪个页面链接过来的,服务器藉此可以获得一些信息用于处理。
比如我们在 Chrome
浏览器的控制台下 可以看到 Request Headers
下有类似如下的信息
Provisional headers are shown Accept: / Origin: local.test5.show Referer: local.test5.show/test/show User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
其中 Referer
就是该属性了
Referer的正确英语拼法是 referrer。由于早期 HTTP 规范的拼写错误,为了保持向后兼容就将错就错了
Referer 的作用
防盗链
比如你发现访问加载自己的资源 而 referer不是自己的站点 就可以屏蔽它
防止恶意请求
这点同上
高级用法
比如微信H5支付 也需要这个 就不知道他们做啥用了(hhh
Referer 丢失
关于 Referer
丢失的问题 首先 referer 是由客户端的浏览器发送到服务器上,且在客户端可以通过 document.referrer
来获取,也就是说referer的发送实际上是一个浏览器行为,发送与否的决定权是在浏览器手里。虽然这样说,但是HTTP协议对什么情况下,浏览器该发送,什么情况下不该发送有着严格的规定。
总结下 Referer 丢失的几种情况
1.当网站使用refresh字段进行跳转的时候,大多数浏览器不发送referer
2.从用户从一个HTTPS的网站点击链接到另一个HTTP的网站时,不发送referer
3.html5中,a标签的rel = “noreferrer”, 可以让浏览器不发送referer
4.使用Data URI scheme链接的,浏览器也不发送referer
5.使用Content Security Policy, 也可以让浏览器不发送referer
6.在html头部中使用meta标签来控制不让浏览器发送referer
自动生成URL链接HTTPS变HTTP
有时候需要在API项目中生成一些URL链接返回 但是服务器端已经配置了支持HTTPS,通过HTTPS访问的时候生成的URL仍然是HTTP
关于这个问题其实是服务器 配置问题 和 下面类似
回到我遇到的微信支付问题 跟踪了一圈浏览器的跳转之后发现是属性第二种情况 从 HTTPS 站点跳到 HTTP 站点 丢失了 Referer【ps:反过来从HTTP到HTTPS是没问题的 不会丢失 Referer】 中间藏的比较深
当然我一开始没有发现这个问题 因为从前端请求到 API 整个都没有问题 全部项目已经全线部署了 HTTPS , Referer 信息也有携带 然后到最后一步微信的支付请求URL的时候 Referer 就丢失了.
后面发现在请求到API项目的时候 API项目返回了一个 URL 给前端 这个 URL 是后端代码根据规则生成的(Laravel 里的 action 辅助函数) 这个函数本身并没有什么问题 但是生成的URL链接 是 HTTP 了 又搞事情!!!
API项目配置的是 HTTPS 请求 但是生成的URL是 HTTP 问题就是这里了 请求运维哥协助 最后发现是 Nginx 反向代理中配置的问题
nginx服务器配置片段如下:
location / { proxy_pass http://114.114.114.114:80; }
可以看到 proxy_pass 参数 指向的是 HTTP的协议 所以在 后台获取的 URL 都是HTTP协议的
把代理这设置成 https://114.114.114.114:443;
即可 问题终解决
以上是“Referer丢失的示例分析”这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注创新互联行业资讯频道!
新闻名称:Referer丢失的示例分析
文章来源:http://ybzwz.com/article/pgjjgg.html