发布网友 发布时间:2024-09-29 10:21
共1个回答
热心网友 时间:2024-09-29 13:26
现在chrome浏览器对http的限制越来越高了,https的网站不在支持访问http的资源
出于安全和跟随大流等原因,我们的网站必然是要用https,然而搭建了https的网站之后,使用中大家会发现一些比较难受的点,http的资源居然被限制了,无法访问,这就难受了,和别人说你不要用chrome浏览器了或者你把chrome降下级,这就感觉都不好,而且并没有解决主要问题
在网上搜了一圈,基本上的技术方案都是前端遇到http的链接,进行强转,把http的协议头改成https的协议头,可https资源不是改协议头就行的,需要有服务端对https的支持,服务端有些时候并不能提供相应的支持
例如在我实际使用中,资源的来源有三种
自己的
合作方提供的
网上的公有资源
自己的,毫无疑问,该上https就上,操作简单,收益高
合作方提供的,比较难搞,合作方会考虑成本原因,历史原因,也会对比他之前的合作方,和你来句,我之前对接过好多家了,都没有问题,你是不是技术不行啊 :)
网上公有资源,这个就很无奈了
遇到了这种必须https的资源,但是原来资源又不支持的,那我们只能在服务端进行处理
当然我们可以用下载的方式,将原始资源存储一份到自己的空间
下面我要说的是另外的一种解决方案,不需要增加额外储存成本,实现方式也简单:
一般网页请求如上图的简单示意,这时候如第三步,加载合作方或者公用资源,就会被chrome拦截,理由是安全保护
之所以说chrome是因为他是这个规则最大的推动者,不过考虑到趋势的话,以后势必其他的浏览器都会跟进
我这边提供的一个方案是用你的服务器做跳板,去获取其它资源
调整之后的模型如上图;
于是我们可以实操一下:
实操的时候会发现两个问题
第一个:怎么让浏览器把请求合作方资源的请求打到你的服务器上
例如你的服务器的域名是https://your.com 合作方的资源是 http://partner.com/0001.jpg?k=1&e=2
我们要让客户端在请求合作方的资源的时候不是通过合作方的域名,而是通过你的域名 这时候请求合作方的资源应该是你的域名+他的资源
https://your.com/http://partner.com/0001.jpg?k=1&e=2
这样简单的拼起来,我们发现几个难受的点
明显的:1. 第二个冒号,2.第二个双斜杆 3. 随意的路径,自己不可控 不明显的: 合作方的链接可能有一些特殊的字符结构,在原来的链接中不会有问题,但是拼在你的域名后面会导致最终生成的url是不符合url生成规范的
所以我们做如下调整
提供一个统一的GET接口.例如: https//your.com/helpGetImage.do
合作方的地址以参数的形式加进来
于是 可得 https//your.com/helpGetImage.do?target=http://partner.com/0001.jpg?k=1&e=2
但是我们可以看到,这个url还是有问题的
合作方的url参数好像成了我们url的参数,从target字段拿出来的合作方的url是不完整的 并且也存在 " 合作方的链接可能有一些特殊的字符结构,在原来的链接中不会有问题,但是拼在你的域名后面会导致最终生成的url是不符合url生成规范的" 这个问题
所以我们不能直接用合作方的url
第二个问题: 怎么去处理合作方的url可以避免上述的问题呢?
只需要考虑编码和解码就可以了,所以我们可用UrlBase64 这个工具去做编码和解码,从而实现
http://partner.com/0001.jpg?k=1&e=2 通过编码后 成为 aHR0cDovL3BhcnRuZXIuY29tLzAwMDEuanBnP2s9MSZlPTI.
这时候我们的链接就成了https//your.com/helpGetImage.do?target=aHR0cDovL3BhcnRuZXIuY29tLzAwMDEuanBnP2s9MSZlPTI.
这样一来,我们就可以放心的获取target的对应url了
当客户端请求https//your.com/helpGetImage.do?target=aHR0cDovL3BhcnRuZXIuY29tLzAwMDEuanBnP2s9MSZlPTI.的时候
我们获取target对应的aHR0cDovL3BhcnRuZXIuY29tLzAwMDEuanBnP2s9MSZlPTI.
把aHR0cDovL3BhcnRuZXIuY29tLzAwMDEuanBnP2s9MSZlPTI.使用UrlBase64.decode,将他恢复成http://partner.com/0001.jpg?k=1&e=2
服务端请求http://partner.com/0001.jpg?k=1&e=2,将获取到的流数据写给前端
前端渲染图片
服务端处理的两处代码简单示意
总结下:
服务端对只支持http的资源进行了资源的转发
目标url在使用的过程中使用了Base64进行编码和解码
可解决http资源限制访问等问题
灵活性高,解决了对合作方/公共资源https的强依赖
低成本方案,不需要大量的空间去存储合作方/公共资源