aisuhua

aisuhua 查看完整档案

广州编辑广东财经大学  |  电子商务 编辑铂涛集团(原 7天连锁酒店演变而来)  |  PHP Engineer 编辑 github.com/aisuhua 编辑
编辑

努力成为一名称职的工匠师

个人动态

aisuhua 收藏了文章 · 2019-03-12

[译] HTML5 媒体源扩展(MSE):把影视制作级别的视频格式带入 Web

英文原文:HTML5 Media Source Extensions: Bringing Production Video To The Web

在过去的十几年,像Flash和Silverlight这样的插件为浏览器开启了丰富的视频功能,壮大了一批视频服务商,如Youtube、Netflix。但是,最近几年的风向却开始转向了HTML5.

大概2年前,W3C组织发布了最终的HTML5标准,其中提供了一组新的HTML元素和APIs,特别是video方面。其中一些旨在为网页增加更多的语义,但不引入新的功能。还有一些扩展了web的可能性,并提高了开发者开发原生web应用可能性,不使用plugins,如Adobe Flash, Microsoft Silverlight 或者 Java

这对前端开发来说非常重要,因为Google已经宣布废除NPAPI(一种plugins使用的API),同时FirefoxMicrosoft方面都号召要无插件浏览web。虽然这些厂商都还支持Flash player,但淘汰掉它看上去只是时间的问题。此外,对于移动端的浏览器来说,他们已经跨过了这一步,因为他们本来就不支持插件方式,根本就没有Flash player

让我们看一下这些新的HTML5元素以及他们对video方面的影响:

  • <canvas>提供了脚本渲染图形,游戏图形等功能。这也叫做Canvas JavaScript API。cancas元素也可以与WebGL结合通过显卡的GPU,来渲染2D和3D图形。

  • <video>实现了即开即用的视屏播放,很牛叉是吧。这也让在Web上实现无插件媒体播放变得可行。实际上,各家浏览器厂商好像都同意用使用一种视频格式-MPEG-4/H.264,这在所有浏览器中已经普遍支持了。不过Opera Mini是一个例外。

  • <audio>实现了在Web网页上即开即用的音频播放。与视频播放一样,支持什么样的格式和编码要看不同的浏览器厂商。

  • <track>用于定时文本内容显示,例如视频中的字幕和提示。WebVTT文件是开箱即用的。

其实大多数新的元素已经很熟悉了,而且使用了一些日子了。这时因为所有的主流浏览器早就开始支持了。虽然现在规范已经稳定,但W3C还是有很多工作要做。

对于我来说,最重要的标准就是W3C还在制定中的媒体源扩展标准(MSEs),该标准现在已经进入了“备选推荐”状态。这些JavaScript API将允许我们为<video><audio>或其他元素解析媒体流,从而实现自适应码率的标准,比如只靠HTML5和JavaScript开发的MPEG-DASH。

还有一个值得关注的是加密媒体扩展标准,其支持用原生HTML5和JavaScript开发播放加密视频。不过,目前这还仅仅是个研究草案,还需要一点时间才能发布。

我们非常欢迎新的标准,期待着再也不用安装各色Flash播放器或者插件,只开发一个Web版本的就可以在任何设备上享受多媒体内容的一天。

为什么是 MPEG-DASH?

让我先简单的介绍以下 MPEG-DASH格式以及为什么会被用在HTML5中。MPEG-DASH(DASH是通过HTTP的动态自适应流的缩写)是由MPEG和ISO(ISO / IEC 23009-1)批准的国际,浏览器厂商独立标准。早先的自适应流技术(例如Apple HLS,Microsoft Smooth Streaming和Adobe HDS)由软件公司独立发布,仅支持自身的流媒体服务标准或者播放客户端。基于某一家公司标准来推广显然是不可取的,因此标准化组织推动各家厂商进行协调,这才有了在2012年推出的MPEG-DASH。

再看一下MPEG-DASH的目标和优点:

  • 在视频播放期间减少启动延迟以及缓冲和停顿。

  • 持续适应客户端的带宽情况。

  • 通过客户端开发的流处理逻辑,来达到最好的扩展性和灵活性。

  • 可以配合CDN降低成本,并使用代理以及缓存服务。

  • 通过使用HTTP有效地绕过NAT和防火墙。

  • 通过信令、分发以及同源多并发的DRM方案来实现一种通用加密方法。

  • 实现流媒体简单的拼接,以及广告内容在指定位置插入功能。

  • 更好的支持“特效模式”

  • 其他

近几年,MPEG-DASH已经集成到新的标准化工作中,比如HTML5的MSE,MSE可以通过HTML5的videoaudio标签实现DASH播放,以及HTML5加密多媒体格式扩展,即在浏览器中播放用DRM加密的多媒体内容。此外,MPEG-DASH中的DRM加密方式可以很好的协调其他的通用加密系统,如MPEG-CENC。并且MPEG-DASH还可以很容易的通过Hybrid方式的广播宽带电视集成到不同的只能电视平台上,如HbbTV 1.5HbbTV 2.0

此外,MPEG-DASH标准的使用方法已经被DASH行业社区以及DASH-AVC/264组织所推荐,同时,像DASH-HEVC/265这样前瞻性的计划,也已经推荐使用MPEG-DASH结合H.265/HEVC这样的方式。

视频流标准的生态圈

视频流标准的生态圈 (Image: Bitcodin) (大图点击)

今天,MPEG-DASH已经越来越多的被部署,并且随着Netflix以及Google这样的服务商的不断升级,他们都已经开始转向MPEG-DASH这一标准。依靠这两个主要的流量来源,MPEG-DASH先进已占整个互联网总流量的50%。

MSEs是如何工作的?

现在,让我们深入的去了解一下MSEs,以及开发者如何使用他们。MSEs是HTMLMediaElement元素的扩展规范,通过它可以让JavaScript有能力去动态处理videoaudio 这样的媒体流。这种功能在过去是不可能的,因为以前这些媒体标签只能加载MP4这样的完整文件。这种方法也被称为渐进式流处理,或者渐进式下载,因为媒体文件的下载和播放并行工作,开启了pseudo-streaming模式。

可是,这只带来了很差的搜索能力,并且根本没有办法来实现根据用户的带宽状况调整视频音频的清晰度。通过由JavaScript处理过的媒体数据,再输入给videoaudio标签,这样开发者动态适应视频数据对应上用户的环境,从而提升媒体播放的体验。

如上所述,MPEG-DASH是MSEs的一种媒体传输格式的实现。那让我们了解一下基于HTML5 MSE的视频播放器的工作步骤:

  1. 下载并解析配置文件,MPEG-DASH中使用MPD文件(HLS中使用m3u8文件),配置文件中提供了视频流的详细信息,诸如视频流的码率质量种类,分辨率数量,音频数据数量,字幕数量等,以及媒体文件数据块的名字,源服务器或者CDN的信息。

  2. 评估客户端设备上的可用带宽,选择适当的视频质量以实现无缓冲流,截止在用JavaScript来下载后续的媒体片段。

  3. JavaScript代码将下载的媒体片段移交到MSE的缓存中处理。

  4. 底层硬件拿到了这部分缓存,就开始进行解码以及渲染视频,把结果返回给video标签。

这就是一种Netflix和Youtube都在使用的基于HTML5的自适应媒体播放。像dash.jsBitdash HTML5 player都是现今相当成熟的解决方案,这就让开发者和视频内容商很轻松的切换到HTML5的自适应码率播放方案,同时DASH-IF项目是开源的。

MPEG-DASH的支持的格式全部都来自如x264 和 MP4Box这样的开源工具,也有部分来自一些商业编码服务,如 Bitcodin

不过这样,MSEs并不仅限支持MPEG-DASH。有越来越多的项目(如hls.js)和播放器(如Bitdash)都已经实现了通过H5的MSEs方式来支持Apple的HLS格式。他们通过多路转换方式把HLS媒体片段(即MPEG2-TS内容)转成HTML5 和 MPEG-DASH可以处理的符合ISO的媒体文件格式。

DRM加密媒体扩展

主要变化发生在DRM市场,由于Chrome 和 Firefox中NPAPI插件的减少,导致向Silverlight这种,DRM系统的领先者开始失去优势。这使得大多数的专业内容供应商处境变得十分困难,因为他们必须转换新技术,找到一个面向未来的新解决方案。

专业流媒体发布商将无法依靠微软的PlayReady DRM技术在PC和安卓设备上的Chrome、火狐来加密自己的内容。他们必须重新评估他们的内容保护和流平台战略,并且找到一种新的解决方案,快速切换过去。

对许多视频服务商来说,MPEG-DASH已经是最好的技术选型。DASH项目以越来越快的速度推出,使用Widevine DRM的MES和EME看起来是最可行的替代方案。此外,MPEG-CENC可以支持不同的DRM系统都只支持同一版本的加密内容,并且,EME的内容是基于MSE的MPEG-DASH内容格式。

因此,不同的DRM系统组合,如用于Chrome和安卓的Widevine Modular,用于IE和Edge的Microsoft PlayReady,还有用于Firefox的Adobe Primetime。由于每一个平台都要有一个版本,这使得内容供应商有了更多的动机去转向MPEG-DASH作为国际标准,因为它对流媒体、DRM以及CDN都具有更好的灵活性。

浏览器对于MSEs和EMEs的支持情况

浏览器厂家在经历了很多年对HTML5以及MSE的缓慢适配之后,我们很高兴的看到如今大多数的主流浏览器都已经支持了。这样的过程,也同样会发生在EME身上,虽然目前各家厂商都有自己的DRM系统,这让目前的DRM的生态系统变得有点复杂。

尽管如此,要覆盖99%的用户,我们需要做一个视频流兼容设置,这样也可以让那些不支持MSE的浏览器也能顺利播放,比如一些旧版本的浏览器,和iOS上的Safari。老的浏览器可以使用Flash播放器来提供服务,Flash播放器是可以直接播放MSE的MPEG-DASH格式内容的,如Bitdash player播放器。为了支持iOS设备,我们必须要使用Apple的HLS流媒体格式,这是苹果在HTML5中强推的另一种方式。Apple并不喜欢支持开放标准(如MSE),不过Mac OSX上的Safari还是支持MSE的。

下面的列表介绍了现在主流的浏览器对MSE和EME支持的现状,由Bitmovin提供:

EnvironmentPlayer TechnologyMediaDRM
ChromeHTML5 MSEMPEG-DASHWidevine Modular
Internet Explorer 11 Windows 8.1HTML5 MSEMPEG-DASHPlayReady
Internet Explorer (other)Flash, SilverlightMPEG-DASHClearKey, PlayReady
EdgeHTML5 MSE, HTML5 HLSMPEG-DASH, HLSPlayReady, AES HLS
FirefoxHTML5 MSEMPEG-DASHAdobe
SafariHTML5 MSE, HTML5 HLSMPEG-DASH, HLSFairplay, AES
Android: Web > v4.1HTML5 MSE, HTML5 HLSMPEG-DASH, HLSWidevine Modular
Android: appGoogle’s ExoplayerMPEG-DASH, HLSWidevine Modular
iOS: webHTML5 HLSHLSAES
iOS: appnative HLS supportHLSFairplay, AES
smart TVNative MPEG-DASH support or HTML5 MSE (e.g. Tizen)MPEG-DASH or HLSDevice-dependent
HbbTV (1.5)native MPEG-DASH supportMPEG-DASHdevice-dependent

HTML5 Video的未来

新的媒体解码器正在进入市场,这使得视频压缩效率变得更高,这对于那些高质量的格式(如4K和UHD)以及那些移动端设备的流媒体尤为重要。最常见的编解码器是HEVC/h.265,它是十几年至今一直选用的默认编解码格式(当然如果他的专利肯定不发生变化)。同时他还可以利用浏览器内置的MSEs进行播放,并使用MPEG-DASH作为流格式,这表明了这种开发标准的灵活性。

视频播放器的开发者值需要启动一种简单的适配,比如在创建SourceBuffer时改变编解码器的属性。并且,浏览器底层已经集成了HEVC解码(最有可能是硬件解码器),那么你就可以在HTML5中观看基于HEVC MPEG-DASH的流媒体。我们已经成功在在一些浏览器中测试过了,比如Microsoft Edge,其已经支持了HEVC;而且Google最近声称它的Chromium browser也会支持。

然而,HEVC还不能为绝大多数互联网视频资源所用,而且也只有不多的一部分设备能支出对其的硬解码。当然,它并不是世界上唯一的一种编解码器。VP9,一种开放的免版税的视频编码格式(VP8的继任者),它旨在提供更好的编码效率,现在诸如Google Chrome和Microsoft Edge这些主流浏览器已经支持VP9,并且VP9可以很好的与MSE兼容。不过,我们并不能预见未来那些编解码器会成为我们的主流。但不管是VP8/9, AVC 还是 HEVC,MSEs和MPEG-DASH都已经准备好了!

现在,360度视频即将普及,这可以非常直观的通过HTML5来观看。开发者可以利用MSE的流自适应功能来实现360度视频的体验,只需要结合一些JavaScript代码或WebGL渲染层。最近,我做了一个小演讲,是关于如何用HTML5,JavaScript,DASH以及WebGL实现一套跟Netflix服务类似的虚拟现实系统。

小结

我希望这篇文章可以让你大概的了解一下网络视频的现状和未来。MSE跟EME是网络视频迈向开放生态系统的重要一步,他们取代了Flash和Silverlight。此外,HTML5技术已经被现如今各种平台所选用,包括桌面端,移动端,还有智能电视平台。

结合像MPEG-DASH这样的流媒体标准,视频内容供应商还可以在不同平台和设备之间拥有统一的视频解决方案。他们可以通过自适应流媒体格式来防止发生缓冲,减少视频加载时间,提高用户观看体验,并根据每一个用户自身的带宽和设备情况提供最匹配的视频画质。

查看原文

aisuhua 赞了文章 · 2018-12-17

聊聊二维码登录

本文主要来研究一下二维码登录的相关场景和原理。

场景

主要的场景有如下几个:

  • app扫二维码登录pc版系统

比如微信web版,在手机端微信登录的前提下,扫二维码确认,自动登录网页版。这里的app可以分为两大类,一个是自有的app,一个是第三方的app。

自己的app自有认证体系,在登录前提下完成pc端的扫描登录。
第三方app扫描登录场景,比如使用手机端的微信APP扫描登录PC端系统,这种情况下,一般是利用微信的oauth体系,服务端完成自有账户体系与微信账号的绑定,然后实现PC端的自动登录
  • app扫二维码作为双因素验证

比如微信公众号平台,在账户密码登录PC端的情况下,再使用手机端微信登录的前提下,扫描二维码再次确认,登录网页版

  • Secure QR Login (SQRL)

完全使用二维码登录,替代用户密码。这个有SQRL协议及相关实现。

步骤

以下所有的都基于这个前提,就是手机app已经登录,自带有登录的凭证,然后要扫描登录pc端的系统

  • 打开pc端显示登录二维码(pc端未登录的前提下)
这个时候请求服务端生成一个登陆二维码
服务端生成二维码,该二维码包含了这个pc端的唯一标识,比如sessionId,或者是新生成一个uuid跟这个sessionId关联
  • pc端同时开启轮询(有长连接等其他实现,这里以轮询方式介绍)
获取二维码之后,pc端开启定时轮询,轮询二维码的状态,主要有如下状态:NEW,SCANED,CONFIRMED,REFUSED,EXPIRED
  • 手机端扫描二维码
手机端已经登录的情况下,扫描网页二维码,二维码状态变为已扫描,然后手机端跳转到确认页面
  • 手机端确认
手机端扫描二维码之后,点击确认,二维码状态变为确认
  • pc端跳转成功/二维码过期/拒绝
二维码状态变为确认之后,跳转自动登录,完成PC端登录态建立
如果app端拒绝这次请求,则二维码状态变为被拒绝,不再轮询
如果二维码状态在一定时间没有变化,则显示二维码过期,不再轮询

PC客户端

  • 请求登录二维码
  • 轮询二维码状态
  • 跳到到登陆后的页面

手机客户端

  • 扫描登录二维码
  • 确认登录

服务端

  • 生成登录二维码,绑定二维码与pc客户端
  • 处理二维码轮询
  • 处理手机端扫描二维码
  • 处理手机端确认二维码登录
  • 处理pc端自动登录

实现

PC端如何自动登录

这个问题相当于同一个帐号多设备同时登录的问题

在二维码被具有登录态的app端扫描确认之后,PC端如何完成自动登录。有如下几个方案:

  • session拷贝
其实就是在原来基于账号密码的登录鉴权逻辑基础上,新增支持无需账号密码的登录。也就相当于绕过了基于用户名密码,内部重新设置了一个登录态
如果是基于session的鉴权,相当于基于原有的一个已经鉴权的session,拷贝信息到另外一个新的session中,在server端关联
  • 复用已有token
如果是基于token的鉴权,一种方案就是复用token,让pc端也复用手机app端的token,这样的好处是原来基于token的鉴权逻辑都不用改
  • 仿照oauth授权颁发新token
整个过程其实有点像oauth,pc端是client,server端是资源和认证中心,手机端是具有登录态的用户。手机端扫描二维码,然后用户确认授权,server端给pc端颁发token,然后pc端就可以访问server端的资源了。这种就在原来的认证基础上支持另外一类oauth的token校验,貌似有点复杂
另外一个变形是新颁发token,但跟app端的token有个关联映射,最终鉴权的时候还去找原来授权的token去鉴权,这样的好处是原来的token失效,经过它授权的token也失效

二维码过期

一种是基于redis来做过期,一种是使用数据库,但是设置expired time来判断

安全问题

QRLJacking全称Quick Response Code Login Jacking,是session劫持的一种。

原理

具体是怎么劫持的呢,假设攻击者将web登录二维码伪装为公众号二维码,让用户去扫描,用户一不小心点击确认,攻击者的就可以登录用户的web系统,或者利用那个token/session去盗取用户的相关信息或做相关操作。

防范

  • 二维码超时机制

二维码增加超时机制之后,会增加攻击者攻击的难度,不过攻击者也可能利用脚本去自动刷新二维码

  • 确认机制

二维码扫描一定要有这个确认的页面,明确告知用户要做的操作,假设没有确认这个环节,那么是极其容易上当的。另外,二维码扫描确认之后,再往用户app或手机等发送登录提醒的通知,告知如果不是本人登录的,则建议用户立即修改密码

  • Sound-based Authentication

确认阶段改为双边语音确认,而不是简单的用户点击确认按钮。语音是根据用户id、二维码id等加密生成,在app端播放,然后pc端语音识别之后才能完成整个登录过程。这个可以有效防止远程攻击。同样的思路,改语音为one time password也行,增加了确认过程的复杂度,也就增加了攻击的难度。

小结

二维码扫描登录是个挺潮流的功能,这要求既有系统增加改造,也要求针对这种形式的登录带来潜在的攻击进行安全防范。

doc

查看原文

赞 96 收藏 504 评论 4

aisuhua 收藏了文章 · 2018-12-17

聊聊二维码登录

本文主要来研究一下二维码登录的相关场景和原理。

场景

主要的场景有如下几个:

  • app扫二维码登录pc版系统

比如微信web版,在手机端微信登录的前提下,扫二维码确认,自动登录网页版。这里的app可以分为两大类,一个是自有的app,一个是第三方的app。

自己的app自有认证体系,在登录前提下完成pc端的扫描登录。
第三方app扫描登录场景,比如使用手机端的微信APP扫描登录PC端系统,这种情况下,一般是利用微信的oauth体系,服务端完成自有账户体系与微信账号的绑定,然后实现PC端的自动登录
  • app扫二维码作为双因素验证

比如微信公众号平台,在账户密码登录PC端的情况下,再使用手机端微信登录的前提下,扫描二维码再次确认,登录网页版

  • Secure QR Login (SQRL)

完全使用二维码登录,替代用户密码。这个有SQRL协议及相关实现。

步骤

以下所有的都基于这个前提,就是手机app已经登录,自带有登录的凭证,然后要扫描登录pc端的系统

  • 打开pc端显示登录二维码(pc端未登录的前提下)
这个时候请求服务端生成一个登陆二维码
服务端生成二维码,该二维码包含了这个pc端的唯一标识,比如sessionId,或者是新生成一个uuid跟这个sessionId关联
  • pc端同时开启轮询(有长连接等其他实现,这里以轮询方式介绍)
获取二维码之后,pc端开启定时轮询,轮询二维码的状态,主要有如下状态:NEW,SCANED,CONFIRMED,REFUSED,EXPIRED
  • 手机端扫描二维码
手机端已经登录的情况下,扫描网页二维码,二维码状态变为已扫描,然后手机端跳转到确认页面
  • 手机端确认
手机端扫描二维码之后,点击确认,二维码状态变为确认
  • pc端跳转成功/二维码过期/拒绝
二维码状态变为确认之后,跳转自动登录,完成PC端登录态建立
如果app端拒绝这次请求,则二维码状态变为被拒绝,不再轮询
如果二维码状态在一定时间没有变化,则显示二维码过期,不再轮询

PC客户端

  • 请求登录二维码
  • 轮询二维码状态
  • 跳到到登陆后的页面

手机客户端

  • 扫描登录二维码
  • 确认登录

服务端

  • 生成登录二维码,绑定二维码与pc客户端
  • 处理二维码轮询
  • 处理手机端扫描二维码
  • 处理手机端确认二维码登录
  • 处理pc端自动登录

实现

PC端如何自动登录

这个问题相当于同一个帐号多设备同时登录的问题

在二维码被具有登录态的app端扫描确认之后,PC端如何完成自动登录。有如下几个方案:

  • session拷贝
其实就是在原来基于账号密码的登录鉴权逻辑基础上,新增支持无需账号密码的登录。也就相当于绕过了基于用户名密码,内部重新设置了一个登录态
如果是基于session的鉴权,相当于基于原有的一个已经鉴权的session,拷贝信息到另外一个新的session中,在server端关联
  • 复用已有token
如果是基于token的鉴权,一种方案就是复用token,让pc端也复用手机app端的token,这样的好处是原来基于token的鉴权逻辑都不用改
  • 仿照oauth授权颁发新token
整个过程其实有点像oauth,pc端是client,server端是资源和认证中心,手机端是具有登录态的用户。手机端扫描二维码,然后用户确认授权,server端给pc端颁发token,然后pc端就可以访问server端的资源了。这种就在原来的认证基础上支持另外一类oauth的token校验,貌似有点复杂
另外一个变形是新颁发token,但跟app端的token有个关联映射,最终鉴权的时候还去找原来授权的token去鉴权,这样的好处是原来的token失效,经过它授权的token也失效

二维码过期

一种是基于redis来做过期,一种是使用数据库,但是设置expired time来判断

安全问题

QRLJacking全称Quick Response Code Login Jacking,是session劫持的一种。

原理

具体是怎么劫持的呢,假设攻击者将web登录二维码伪装为公众号二维码,让用户去扫描,用户一不小心点击确认,攻击者的就可以登录用户的web系统,或者利用那个token/session去盗取用户的相关信息或做相关操作。

防范

  • 二维码超时机制

二维码增加超时机制之后,会增加攻击者攻击的难度,不过攻击者也可能利用脚本去自动刷新二维码

  • 确认机制

二维码扫描一定要有这个确认的页面,明确告知用户要做的操作,假设没有确认这个环节,那么是极其容易上当的。另外,二维码扫描确认之后,再往用户app或手机等发送登录提醒的通知,告知如果不是本人登录的,则建议用户立即修改密码

  • Sound-based Authentication

确认阶段改为双边语音确认,而不是简单的用户点击确认按钮。语音是根据用户id、二维码id等加密生成,在app端播放,然后pc端语音识别之后才能完成整个登录过程。这个可以有效防止远程攻击。同样的思路,改语音为one time password也行,增加了确认过程的复杂度,也就增加了攻击的难度。

小结

二维码扫描登录是个挺潮流的功能,这要求既有系统增加改造,也要求针对这种形式的登录带来潜在的攻击进行安全防范。

doc

查看原文

aisuhua 收藏了文章 · 2018-11-22

前端常见跨域解决方案(全)

什么是跨域?

跨域是指一个域下的文档或脚本试图去请求另一个域下的资源,这里跨域是广义的。

广义的跨域:

1.) 资源跳转: A链接、重定向、表单提交
2.) 资源嵌入: <link>、<script>、<img>、<frame>等dom标签,还有样式中background:url()、@font-face()等文件外链
3.) 脚本请求: js发起的ajax请求、dom和js对象的跨域操作等

其实我们通常所说的跨域是狭义的,是由浏览器同源策略限制的一类请求场景。

什么是同源策略?
同源策略/SOP(Same origin policy)是一种约定,由Netscape公司1995年引入浏览器,它是浏览器最核心也最基本的安全功能,如果缺少了同源策略,浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同,即便两个不同的域名指向同一个ip地址,也非同源。

同源策略限制以下几种行为:

1.) Cookie、LocalStorage 和 IndexDB 无法读取
2.) DOM 和 Js对象无法获得
3.) AJAX 请求不能发送

常见跨域场景

URL                                      说明                    是否允许通信
http://www.domain.com/a.js
http://www.domain.com/b.js         同一域名,不同文件或路径           允许
http://www.domain.com/lab/c.js

http://www.domain.com:8000/a.js
http://www.domain.com/b.js         同一域名,不同端口                不允许
 
http://www.domain.com/a.js
https://www.domain.com/b.js        同一域名,不同协议                不允许
 
http://www.domain.com/a.js
http://192.168.4.12/b.js           域名和域名对应相同ip              不允许
 
http://www.domain.com/a.js
http://x.domain.com/b.js           主域相同,子域不同                不允许
http://domain.com/c.js
 
http://www.domain1.com/a.js
http://www.domain2.com/b.js        不同域名                         不允许

跨域解决方案

1、 通过jsonp跨域
2、 document.domain + iframe跨域
3、 location.hash + iframe
4、 window.name + iframe跨域
5、 postMessage跨域
6、 跨域资源共享(CORS)
7、 nginx代理跨域
8、 nodejs中间件代理跨域
9、 WebSocket协议跨域

一、 通过jsonp跨域

通常为了减轻web服务器的负载,我们把js、css,img等静态资源分离到另一台独立域名的服务器上,在html页面中再通过相应的标签从不同域名下加载静态资源,而被浏览器允许,基于此原理,我们可以通过动态创建script,再请求一个带参网址实现跨域通信。

1.)原生实现:

 <script>
    var script = document.createElement('script');
    script.type = 'text/javascript';

    // 传参一个回调函数名给后端,方便后端返回时执行这个在前端定义的回调函数
    script.src = 'http://www.domain2.com:8080/login?user=admin&callback=handleCallback';
    document.head.appendChild(script);

    // 回调执行函数
    function handleCallback(res) {
        alert(JSON.stringify(res));
    }
 </script>

服务端返回如下(返回时即执行全局函数):

handleCallback({"status": true, "user": "admin"})

2.)jquery ajax:

$.ajax({
    url: 'http://www.domain2.com:8080/login',
    type: 'get',
    dataType: 'jsonp',  // 请求方式为jsonp
    jsonpCallback: "handleCallback",    // 自定义回调函数名
    data: {}
});

3.)vue.js:

this.$http.jsonp('http://www.domain2.com:8080/login', {
    params: {},
    jsonp: 'handleCallback'
}).then((res) => {
    console.log(res); 
})

后端node.js代码示例:

var querystring = require('querystring');
var http = require('http');
var server = http.createServer();

server.on('request', function(req, res) {
    var params = qs.parse(req.url.split('?')[1]);
    var fn = params.callback;

    // jsonp返回设置
    res.writeHead(200, { 'Content-Type': 'text/javascript' });
    res.write(fn + '(' + JSON.stringify(params) + ')');

    res.end();
});

server.listen('8080');
console.log('Server is running at port 8080...');

jsonp缺点:只能实现get一种请求。

二、 document.domain + iframe跨域

此方案仅限主域相同,子域不同的跨域应用场景。

实现原理:两个页面都通过js强制设置document.domain为基础主域,就实现了同域。

1.)父窗口:(http://www.domain.com/a.html)

<iframe id="iframe" data-original="http://child.domain.com/b.html"></iframe>
<script>
    document.domain = 'domain.com';
    var user = 'admin';
</script>

2.)子窗口:(http://child.domain.com/b.html)

<script>
    document.domain = 'domain.com';
    // 获取父窗口中变量
    alert('get js data from parent ---> ' + window.parent.user);
</script>

三、 location.hash + iframe跨域

实现原理: a欲与b跨域相互通信,通过中间页c来实现。 三个页面,不同域之间利用iframe的location.hash传值,相同域之间直接js访问来通信。

具体实现:A域:a.html -> B域:b.html -> A域:c.html,a与b不同域只能通过hash值单向通信,b与c也不同域也只能单向通信,但c与a同域,所以c可通过parent.parent访问a页面所有对象。

1.)a.html:(http://www.domain1.com/a.html)

<iframe id="iframe" data-original="http://www.domain2.com/b.html" style="display:none;"></iframe>
<script>
    var iframe = document.getElementById('iframe');

    // 向b.html传hash值
    setTimeout(function() {
        iframe.src = iframe.src + '#user=admin';
    }, 1000);
    
    // 开放给同域c.html的回调方法
    function onCallback(res) {
        alert('data from c.html ---> ' + res);
    }
</script>

2.)b.html:(http://www.domain2.com/b.html)

<iframe id="iframe" data-original="http://www.domain1.com/c.html" style="display:none;"></iframe>
<script>
    var iframe = document.getElementById('iframe');

    // 监听a.html传来的hash值,再传给c.html
    window.onhashchange = function () {
        iframe.src = iframe.src + location.hash;
    };
</script>

3.)c.html:(http://www.domain1.com/c.html)

<script>
    // 监听b.html传来的hash值
    window.onhashchange = function () {
        // 再通过操作同域a.html的js回调,将结果传回
        window.parent.parent.onCallback('hello: ' + location.hash.replace('#user=', ''));
    };
</script>

四、 window.name + iframe跨域

window.name属性的独特之处:name值在不同的页面(甚至不同域名)加载后依旧存在,并且可以支持非常长的 name 值(2MB)。

1.)a.html:(http://www.domain1.com/a.html)

var proxy = function(url, callback) {
    var state = 0;
    var iframe = document.createElement('iframe');

    // 加载跨域页面
    iframe.src = url;

    // onload事件会触发2次,第1次加载跨域页,并留存数据于window.name
    iframe.onload = function() {
        if (state === 1) {
            // 第2次onload(同域proxy页)成功后,读取同域window.name中数据
            callback(iframe.contentWindow.name);
            destoryFrame();

        } else if (state === 0) {
            // 第1次onload(跨域页)成功后,切换到同域代理页面
            iframe.contentWindow.location = 'http://www.domain1.com/proxy.html';
            state = 1;
        }
    };

    document.body.appendChild(iframe);

    // 获取数据以后销毁这个iframe,释放内存;这也保证了安全(不被其他域frame js访问)
    function destoryFrame() {
        iframe.contentWindow.document.write('');
        iframe.contentWindow.close();
        document.body.removeChild(iframe);
    }
};

// 请求跨域b页面数据
proxy('http://www.domain2.com/b.html', function(data){
    alert(data);
});

2.)proxy.html:(http://www.domain1.com/proxy....
中间代理页,与a.html同域,内容为空即可。

3.)b.html:(http://www.domain2.com/b.html)

<script>
    window.name = 'This is domain2 data!';
</script>

总结:通过iframe的src属性由外域转向本地域,跨域数据即由iframe的window.name从外域传递到本地域。这个就巧妙地绕过了浏览器的跨域访问限制,但同时它又是安全操作。

五、 postMessage跨域

postMessage是HTML5 XMLHttpRequest Level 2中的API,且是为数不多可以跨域操作的window属性之一,它可用于解决以下方面的问题:
a.) 页面和其打开的新窗口的数据传递
b.) 多窗口之间消息传递
c.) 页面与嵌套的iframe消息传递
d.) 上面三个场景的跨域数据传递

用法:postMessage(data,origin)方法接受两个参数
data: html5规范支持任意基本类型或可复制的对象,但部分浏览器只支持字符串,所以传参时最好用JSON.stringify()序列化。
origin: 协议+主机+端口号,也可以设置为"*",表示可以传递给任意窗口,如果要指定和当前窗口同源的话设置为"/"。

1.)a.html:(http://www.domain1.com/a.html)

<iframe id="iframe" data-original="http://www.domain2.com/b.html" style="display:none;"></iframe>
<script>       
    var iframe = document.getElementById('iframe');
    iframe.onload = function() {
        var data = {
            name: 'aym'
        };
        // 向domain2传送跨域数据
        iframe.contentWindow.postMessage(JSON.stringify(data), 'http://www.domain2.com');
    };

    // 接受domain2返回数据
    window.addEventListener('message', function(e) {
        alert('data from domain2 ---> ' + e.data);
    }, false);
</script>

2.)b.html:(http://www.domain2.com/b.html)

<script>
    // 接收domain1的数据
    window.addEventListener('message', function(e) {
        alert('data from domain1 ---> ' + e.data);

        var data = JSON.parse(e.data);
        if (data) {
            data.number = 16;

            // 处理后再发回domain1
            window.parent.postMessage(JSON.stringify(data), 'http://www.domain1.com');
        }
    }, false);
</script>

六、 跨域资源共享(CORS)

普通跨域请求:只服务端设置Access-Control-Allow-Origin即可,前端无须设置,若要带cookie请求:前后端都需要设置。

需注意的是:由于同源策略的限制,所读取的cookie为跨域请求接口所在域的cookie,而非当前页。如果想实现当前页cookie的写入,可参考下文:七、nginx反向代理中设置proxy_cookie_domain 和 八、NodeJs中间件代理中cookieDomainRewrite参数的设置。

目前,所有浏览器都支持该功能(IE8+:IE8/9需要使用XDomainRequest对象来支持CORS)),CORS也已经成为主流的跨域解决方案。

1、 前端设置:

1.)原生ajax

// 前端设置是否带cookie
xhr.withCredentials = true;

示例代码:

var xhr = new XMLHttpRequest(); // IE8/9需用window.XDomainRequest兼容

// 前端设置是否带cookie
xhr.withCredentials = true;

xhr.open('post', 'http://www.domain2.com:8080/login', true);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.send('user=admin');

xhr.onreadystatechange = function() {
    if (xhr.readyState == 4 && xhr.status == 200) {
        alert(xhr.responseText);
    }
};

2.)jQuery ajax

$.ajax({
    ...
   xhrFields: {
       withCredentials: true    // 前端设置是否带cookie
   },
   crossDomain: true,   // 会让请求头中包含跨域的额外信息,但不会含cookie
    ...
});

3.)vue框架

a.) axios设置:

axios.defaults.withCredentials = true

b.) vue-resource设置:

Vue.http.options.credentials = true
2、 服务端设置:

若后端设置成功,前端浏览器控制台则不会出现跨域报错信息,反之,说明没设成功。

1.)Java后台:

/*
 * 导入包:import javax.servlet.http.HttpServletResponse;
 * 接口参数中定义:HttpServletResponse response
 */

// 允许跨域访问的域名:若有端口需写全(协议+域名+端口),若没有端口末尾不用加'/'
response.setHeader("Access-Control-Allow-Origin", "http://www.domain1.com"); 

// 允许前端带认证cookie:启用此项后,上面的域名不能为'*',必须指定具体的域名,否则浏览器会提示
response.setHeader("Access-Control-Allow-Credentials", "true"); 

// 提示OPTIONS预检时,后端需要设置的两个常用自定义头
response.setHeader("Access-Control-Allow-Headers", "Content-Type,X-Requested-With");

2.)Nodejs后台示例:

var http = require('http');
var server = http.createServer();
var qs = require('querystring');

server.on('request', function(req, res) {
    var postData = '';

    // 数据块接收中
    req.addListener('data', function(chunk) {
        postData += chunk;
    });

    // 数据接收完毕
    req.addListener('end', function() {
        postData = qs.parse(postData);

        // 跨域后台设置
        res.writeHead(200, {
            'Access-Control-Allow-Credentials': 'true',     // 后端允许发送Cookie
            'Access-Control-Allow-Origin': 'http://www.domain1.com',    // 允许访问的域(协议+域名+端口)
            /* 
             * 此处设置的cookie还是domain2的而非domain1,因为后端也不能跨域写cookie(nginx反向代理可以实现),
             * 但只要domain2中写入一次cookie认证,后面的跨域接口都能从domain2中获取cookie,从而实现所有的接口都能跨域访问
             */
            'Set-Cookie': 'l=a123456;Path=/;Domain=www.domain2.com;HttpOnly'  // HttpOnly的作用是让js无法读取cookie
        });

        res.write(JSON.stringify(postData));
        res.end();
    });
});

server.listen('8080');
console.log('Server is running at port 8080...');

七、 nginx代理跨域

1、 nginx配置解决iconfont跨域

浏览器跨域访问js、css、img等常规静态资源被同源策略许可,但iconfont字体文件(eot|otf|ttf|woff|svg)例外,此时可在nginx的静态资源服务器中加入以下配置。

location / {
  add_header Access-Control-Allow-Origin *;
}
2、 nginx反向代理接口跨域

跨域原理: 同源策略是浏览器的安全策略,不是HTTP协议的一部分。服务器端调用HTTP接口只是使用HTTP协议,不会执行JS脚本,不需要同源策略,也就不存在跨越问题。

实现思路:通过nginx配置一个代理服务器(域名与domain1相同,端口不同)做跳板机,反向代理访问domain2接口,并且可以顺便修改cookie中domain信息,方便当前域cookie写入,实现跨域登录。

nginx具体配置:

#proxy服务器
server {
    listen       81;
    server_name  www.domain1.com;

    location / {
        proxy_pass   http://www.domain2.com:8080;  #反向代理
        proxy_cookie_domain www.domain2.com www.domain1.com; #修改cookie里域名
        index  index.html index.htm;

        # 当用webpack-dev-server等中间件代理接口访问nignx时,此时无浏览器参与,故没有同源限制,下面的跨域配置可不启用
        add_header Access-Control-Allow-Origin http://www.domain1.com;  #当前端只跨域不带cookie时,可为*
        add_header Access-Control-Allow-Credentials true;
    }
}

1.) 前端代码示例:

var xhr = new XMLHttpRequest();

// 前端开关:浏览器是否读写cookie
xhr.withCredentials = true;

// 访问nginx中的代理服务器
xhr.open('get', 'http://www.domain1.com:81/?user=admin', true);
xhr.send();

2.) Nodejs后台示例:

var http = require('http');
var server = http.createServer();
var qs = require('querystring');

server.on('request', function(req, res) {
    var params = qs.parse(req.url.substring(2));

    // 向前台写cookie
    res.writeHead(200, {
        'Set-Cookie': 'l=a123456;Path=/;Domain=www.domain2.com;HttpOnly'   // HttpOnly:脚本无法读取
    });

    res.write(JSON.stringify(params));
    res.end();
});

server.listen('8080');
console.log('Server is running at port 8080...');

八、 Nodejs中间件代理跨域

node中间件实现跨域代理,原理大致与nginx相同,都是通过启一个代理服务器,实现数据的转发,也可以通过设置cookieDomainRewrite参数修改响应头中cookie中域名,实现当前域的cookie写入,方便接口登录认证。

1、 非vue框架的跨域(2次跨域)

利用node + express + http-proxy-middleware搭建一个proxy服务器。

1.)前端代码示例:

var xhr = new XMLHttpRequest();

// 前端开关:浏览器是否读写cookie
xhr.withCredentials = true;

// 访问http-proxy-middleware代理服务器
xhr.open('get', 'http://www.domain1.com:3000/login?user=admin', true);
xhr.send();

2.)中间件服务器:

var express = require('express');
var proxy = require('http-proxy-middleware');
var app = express();

app.use('/', proxy({
    // 代理跨域目标接口
    target: 'http://www.domain2.com:8080',
    changeOrigin: true,

    // 修改响应头信息,实现跨域并允许带cookie
    onProxyRes: function(proxyRes, req, res) {
        res.header('Access-Control-Allow-Origin', 'http://www.domain1.com');
        res.header('Access-Control-Allow-Credentials', 'true');
    },

    // 修改响应信息中的cookie域名
    cookieDomainRewrite: 'www.domain1.com'  // 可以为false,表示不修改
}));

app.listen(3000);
console.log('Proxy server is listen at port 3000...');

3.)Nodejs后台同(六:nginx)

2、 vue框架的跨域(1次跨域)

利用node + webpack + webpack-dev-server代理接口跨域。在开发环境下,由于vue渲染服务和接口代理服务都是webpack-dev-server同一个,所以页面与代理接口之间不再跨域,无须设置headers跨域信息了。

webpack.config.js部分配置:

module.exports = {
    entry: {},
    module: {},
    ...
    devServer: {
        historyApiFallback: true,
        proxy: [{
            context: '/login',
            target: 'http://www.domain2.com:8080',  // 代理跨域目标接口
            changeOrigin: true,
            secure: false,  // 当代理某些https服务报错时用
            cookieDomainRewrite: 'www.domain1.com'  // 可以为false,表示不修改
        }],
        noInfo: true
    }
}

九、 WebSocket协议跨域

WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双工通信,同时允许跨域通讯,是server push技术的一种很好的实现。
原生WebSocket API使用起来不太方便,我们使用Socket.io,它很好地封装了webSocket接口,提供了更简单、灵活的接口,也对不支持webSocket的浏览器提供了向下兼容。

1.)前端代码:

<div>user input:<input type="text"></div>
<script data-original="https://cdn.bootcss.com/socket.io/2.2.0/socket.io.js"></script>
<script>
var socket = io('http://www.domain2.com:8080');

// 连接成功处理
socket.on('connect', function() {
    // 监听服务端消息
    socket.on('message', function(msg) {
        console.log('data from server: ---> ' + msg); 
    });

    // 监听服务端关闭
    socket.on('disconnect', function() { 
        console.log('Server socket has closed.'); 
    });
});

document.getElementsByTagName('input')[0].onblur = function() {
    socket.send(this.value);
};
</script>

2.)Nodejs socket后台:

var http = require('http');
var socket = require('socket.io');

// 启http服务
var server = http.createServer(function(req, res) {
    res.writeHead(200, {
        'Content-type': 'text/html'
    });
    res.end();
});

server.listen('8080');
console.log('Server is running at port 8080...');

// 监听socket连接
socket.listen(server).on('connection', function(client) {
    // 接收信息
    client.on('message', function(msg) {
        client.send('hello:' + msg);
        console.log('data from client: ---> ' + msg);
    });

    // 断开处理
    client.on('disconnect', function() {
        console.log('Client socket has closed.'); 
    });
});
查看原文

aisuhua 赞了文章 · 2018-11-22

前端常见跨域解决方案(全)

什么是跨域?

跨域是指一个域下的文档或脚本试图去请求另一个域下的资源,这里跨域是广义的。

广义的跨域:

1.) 资源跳转: A链接、重定向、表单提交
2.) 资源嵌入: <link>、<script>、<img>、<frame>等dom标签,还有样式中background:url()、@font-face()等文件外链
3.) 脚本请求: js发起的ajax请求、dom和js对象的跨域操作等

其实我们通常所说的跨域是狭义的,是由浏览器同源策略限制的一类请求场景。

什么是同源策略?
同源策略/SOP(Same origin policy)是一种约定,由Netscape公司1995年引入浏览器,它是浏览器最核心也最基本的安全功能,如果缺少了同源策略,浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同,即便两个不同的域名指向同一个ip地址,也非同源。

同源策略限制以下几种行为:

1.) Cookie、LocalStorage 和 IndexDB 无法读取
2.) DOM 和 Js对象无法获得
3.) AJAX 请求不能发送

常见跨域场景

URL                                      说明                    是否允许通信
http://www.domain.com/a.js
http://www.domain.com/b.js         同一域名,不同文件或路径           允许
http://www.domain.com/lab/c.js

http://www.domain.com:8000/a.js
http://www.domain.com/b.js         同一域名,不同端口                不允许
 
http://www.domain.com/a.js
https://www.domain.com/b.js        同一域名,不同协议                不允许
 
http://www.domain.com/a.js
http://192.168.4.12/b.js           域名和域名对应相同ip              不允许
 
http://www.domain.com/a.js
http://x.domain.com/b.js           主域相同,子域不同                不允许
http://domain.com/c.js
 
http://www.domain1.com/a.js
http://www.domain2.com/b.js        不同域名                         不允许

跨域解决方案

1、 通过jsonp跨域
2、 document.domain + iframe跨域
3、 location.hash + iframe
4、 window.name + iframe跨域
5、 postMessage跨域
6、 跨域资源共享(CORS)
7、 nginx代理跨域
8、 nodejs中间件代理跨域
9、 WebSocket协议跨域

一、 通过jsonp跨域

通常为了减轻web服务器的负载,我们把js、css,img等静态资源分离到另一台独立域名的服务器上,在html页面中再通过相应的标签从不同域名下加载静态资源,而被浏览器允许,基于此原理,我们可以通过动态创建script,再请求一个带参网址实现跨域通信。

1.)原生实现:

 <script>
    var script = document.createElement('script');
    script.type = 'text/javascript';

    // 传参一个回调函数名给后端,方便后端返回时执行这个在前端定义的回调函数
    script.src = 'http://www.domain2.com:8080/login?user=admin&callback=handleCallback';
    document.head.appendChild(script);

    // 回调执行函数
    function handleCallback(res) {
        alert(JSON.stringify(res));
    }
 </script>

服务端返回如下(返回时即执行全局函数):

handleCallback({"status": true, "user": "admin"})

2.)jquery ajax:

$.ajax({
    url: 'http://www.domain2.com:8080/login',
    type: 'get',
    dataType: 'jsonp',  // 请求方式为jsonp
    jsonpCallback: "handleCallback",    // 自定义回调函数名
    data: {}
});

3.)vue.js:

this.$http.jsonp('http://www.domain2.com:8080/login', {
    params: {},
    jsonp: 'handleCallback'
}).then((res) => {
    console.log(res); 
})

后端node.js代码示例:

var querystring = require('querystring');
var http = require('http');
var server = http.createServer();

server.on('request', function(req, res) {
    var params = qs.parse(req.url.split('?')[1]);
    var fn = params.callback;

    // jsonp返回设置
    res.writeHead(200, { 'Content-Type': 'text/javascript' });
    res.write(fn + '(' + JSON.stringify(params) + ')');

    res.end();
});

server.listen('8080');
console.log('Server is running at port 8080...');

jsonp缺点:只能实现get一种请求。

二、 document.domain + iframe跨域

此方案仅限主域相同,子域不同的跨域应用场景。

实现原理:两个页面都通过js强制设置document.domain为基础主域,就实现了同域。

1.)父窗口:(http://www.domain.com/a.html)

<iframe id="iframe" data-original="http://child.domain.com/b.html"></iframe>
<script>
    document.domain = 'domain.com';
    var user = 'admin';
</script>

2.)子窗口:(http://child.domain.com/b.html)

<script>
    document.domain = 'domain.com';
    // 获取父窗口中变量
    alert('get js data from parent ---> ' + window.parent.user);
</script>

三、 location.hash + iframe跨域

实现原理: a欲与b跨域相互通信,通过中间页c来实现。 三个页面,不同域之间利用iframe的location.hash传值,相同域之间直接js访问来通信。

具体实现:A域:a.html -> B域:b.html -> A域:c.html,a与b不同域只能通过hash值单向通信,b与c也不同域也只能单向通信,但c与a同域,所以c可通过parent.parent访问a页面所有对象。

1.)a.html:(http://www.domain1.com/a.html)

<iframe id="iframe" data-original="http://www.domain2.com/b.html" style="display:none;"></iframe>
<script>
    var iframe = document.getElementById('iframe');

    // 向b.html传hash值
    setTimeout(function() {
        iframe.src = iframe.src + '#user=admin';
    }, 1000);
    
    // 开放给同域c.html的回调方法
    function onCallback(res) {
        alert('data from c.html ---> ' + res);
    }
</script>

2.)b.html:(http://www.domain2.com/b.html)

<iframe id="iframe" data-original="http://www.domain1.com/c.html" style="display:none;"></iframe>
<script>
    var iframe = document.getElementById('iframe');

    // 监听a.html传来的hash值,再传给c.html
    window.onhashchange = function () {
        iframe.src = iframe.src + location.hash;
    };
</script>

3.)c.html:(http://www.domain1.com/c.html)

<script>
    // 监听b.html传来的hash值
    window.onhashchange = function () {
        // 再通过操作同域a.html的js回调,将结果传回
        window.parent.parent.onCallback('hello: ' + location.hash.replace('#user=', ''));
    };
</script>

四、 window.name + iframe跨域

window.name属性的独特之处:name值在不同的页面(甚至不同域名)加载后依旧存在,并且可以支持非常长的 name 值(2MB)。

1.)a.html:(http://www.domain1.com/a.html)

var proxy = function(url, callback) {
    var state = 0;
    var iframe = document.createElement('iframe');

    // 加载跨域页面
    iframe.src = url;

    // onload事件会触发2次,第1次加载跨域页,并留存数据于window.name
    iframe.onload = function() {
        if (state === 1) {
            // 第2次onload(同域proxy页)成功后,读取同域window.name中数据
            callback(iframe.contentWindow.name);
            destoryFrame();

        } else if (state === 0) {
            // 第1次onload(跨域页)成功后,切换到同域代理页面
            iframe.contentWindow.location = 'http://www.domain1.com/proxy.html';
            state = 1;
        }
    };

    document.body.appendChild(iframe);

    // 获取数据以后销毁这个iframe,释放内存;这也保证了安全(不被其他域frame js访问)
    function destoryFrame() {
        iframe.contentWindow.document.write('');
        iframe.contentWindow.close();
        document.body.removeChild(iframe);
    }
};

// 请求跨域b页面数据
proxy('http://www.domain2.com/b.html', function(data){
    alert(data);
});

2.)proxy.html:(http://www.domain1.com/proxy....
中间代理页,与a.html同域,内容为空即可。

3.)b.html:(http://www.domain2.com/b.html)

<script>
    window.name = 'This is domain2 data!';
</script>

总结:通过iframe的src属性由外域转向本地域,跨域数据即由iframe的window.name从外域传递到本地域。这个就巧妙地绕过了浏览器的跨域访问限制,但同时它又是安全操作。

五、 postMessage跨域

postMessage是HTML5 XMLHttpRequest Level 2中的API,且是为数不多可以跨域操作的window属性之一,它可用于解决以下方面的问题:
a.) 页面和其打开的新窗口的数据传递
b.) 多窗口之间消息传递
c.) 页面与嵌套的iframe消息传递
d.) 上面三个场景的跨域数据传递

用法:postMessage(data,origin)方法接受两个参数
data: html5规范支持任意基本类型或可复制的对象,但部分浏览器只支持字符串,所以传参时最好用JSON.stringify()序列化。
origin: 协议+主机+端口号,也可以设置为"*",表示可以传递给任意窗口,如果要指定和当前窗口同源的话设置为"/"。

1.)a.html:(http://www.domain1.com/a.html)

<iframe id="iframe" data-original="http://www.domain2.com/b.html" style="display:none;"></iframe>
<script>       
    var iframe = document.getElementById('iframe');
    iframe.onload = function() {
        var data = {
            name: 'aym'
        };
        // 向domain2传送跨域数据
        iframe.contentWindow.postMessage(JSON.stringify(data), 'http://www.domain2.com');
    };

    // 接受domain2返回数据
    window.addEventListener('message', function(e) {
        alert('data from domain2 ---> ' + e.data);
    }, false);
</script>

2.)b.html:(http://www.domain2.com/b.html)

<script>
    // 接收domain1的数据
    window.addEventListener('message', function(e) {
        alert('data from domain1 ---> ' + e.data);

        var data = JSON.parse(e.data);
        if (data) {
            data.number = 16;

            // 处理后再发回domain1
            window.parent.postMessage(JSON.stringify(data), 'http://www.domain1.com');
        }
    }, false);
</script>

六、 跨域资源共享(CORS)

普通跨域请求:只服务端设置Access-Control-Allow-Origin即可,前端无须设置,若要带cookie请求:前后端都需要设置。

需注意的是:由于同源策略的限制,所读取的cookie为跨域请求接口所在域的cookie,而非当前页。如果想实现当前页cookie的写入,可参考下文:七、nginx反向代理中设置proxy_cookie_domain 和 八、NodeJs中间件代理中cookieDomainRewrite参数的设置。

目前,所有浏览器都支持该功能(IE8+:IE8/9需要使用XDomainRequest对象来支持CORS)),CORS也已经成为主流的跨域解决方案。

1、 前端设置:

1.)原生ajax

// 前端设置是否带cookie
xhr.withCredentials = true;

示例代码:

var xhr = new XMLHttpRequest(); // IE8/9需用window.XDomainRequest兼容

// 前端设置是否带cookie
xhr.withCredentials = true;

xhr.open('post', 'http://www.domain2.com:8080/login', true);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.send('user=admin');

xhr.onreadystatechange = function() {
    if (xhr.readyState == 4 && xhr.status == 200) {
        alert(xhr.responseText);
    }
};

2.)jQuery ajax

$.ajax({
    ...
   xhrFields: {
       withCredentials: true    // 前端设置是否带cookie
   },
   crossDomain: true,   // 会让请求头中包含跨域的额外信息,但不会含cookie
    ...
});

3.)vue框架

a.) axios设置:

axios.defaults.withCredentials = true

b.) vue-resource设置:

Vue.http.options.credentials = true
2、 服务端设置:

若后端设置成功,前端浏览器控制台则不会出现跨域报错信息,反之,说明没设成功。

1.)Java后台:

/*
 * 导入包:import javax.servlet.http.HttpServletResponse;
 * 接口参数中定义:HttpServletResponse response
 */

// 允许跨域访问的域名:若有端口需写全(协议+域名+端口),若没有端口末尾不用加'/'
response.setHeader("Access-Control-Allow-Origin", "http://www.domain1.com"); 

// 允许前端带认证cookie:启用此项后,上面的域名不能为'*',必须指定具体的域名,否则浏览器会提示
response.setHeader("Access-Control-Allow-Credentials", "true"); 

// 提示OPTIONS预检时,后端需要设置的两个常用自定义头
response.setHeader("Access-Control-Allow-Headers", "Content-Type,X-Requested-With");

2.)Nodejs后台示例:

var http = require('http');
var server = http.createServer();
var qs = require('querystring');

server.on('request', function(req, res) {
    var postData = '';

    // 数据块接收中
    req.addListener('data', function(chunk) {
        postData += chunk;
    });

    // 数据接收完毕
    req.addListener('end', function() {
        postData = qs.parse(postData);

        // 跨域后台设置
        res.writeHead(200, {
            'Access-Control-Allow-Credentials': 'true',     // 后端允许发送Cookie
            'Access-Control-Allow-Origin': 'http://www.domain1.com',    // 允许访问的域(协议+域名+端口)
            /* 
             * 此处设置的cookie还是domain2的而非domain1,因为后端也不能跨域写cookie(nginx反向代理可以实现),
             * 但只要domain2中写入一次cookie认证,后面的跨域接口都能从domain2中获取cookie,从而实现所有的接口都能跨域访问
             */
            'Set-Cookie': 'l=a123456;Path=/;Domain=www.domain2.com;HttpOnly'  // HttpOnly的作用是让js无法读取cookie
        });

        res.write(JSON.stringify(postData));
        res.end();
    });
});

server.listen('8080');
console.log('Server is running at port 8080...');

七、 nginx代理跨域

1、 nginx配置解决iconfont跨域

浏览器跨域访问js、css、img等常规静态资源被同源策略许可,但iconfont字体文件(eot|otf|ttf|woff|svg)例外,此时可在nginx的静态资源服务器中加入以下配置。

location / {
  add_header Access-Control-Allow-Origin *;
}
2、 nginx反向代理接口跨域

跨域原理: 同源策略是浏览器的安全策略,不是HTTP协议的一部分。服务器端调用HTTP接口只是使用HTTP协议,不会执行JS脚本,不需要同源策略,也就不存在跨越问题。

实现思路:通过nginx配置一个代理服务器(域名与domain1相同,端口不同)做跳板机,反向代理访问domain2接口,并且可以顺便修改cookie中domain信息,方便当前域cookie写入,实现跨域登录。

nginx具体配置:

#proxy服务器
server {
    listen       81;
    server_name  www.domain1.com;

    location / {
        proxy_pass   http://www.domain2.com:8080;  #反向代理
        proxy_cookie_domain www.domain2.com www.domain1.com; #修改cookie里域名
        index  index.html index.htm;

        # 当用webpack-dev-server等中间件代理接口访问nignx时,此时无浏览器参与,故没有同源限制,下面的跨域配置可不启用
        add_header Access-Control-Allow-Origin http://www.domain1.com;  #当前端只跨域不带cookie时,可为*
        add_header Access-Control-Allow-Credentials true;
    }
}

1.) 前端代码示例:

var xhr = new XMLHttpRequest();

// 前端开关:浏览器是否读写cookie
xhr.withCredentials = true;

// 访问nginx中的代理服务器
xhr.open('get', 'http://www.domain1.com:81/?user=admin', true);
xhr.send();

2.) Nodejs后台示例:

var http = require('http');
var server = http.createServer();
var qs = require('querystring');

server.on('request', function(req, res) {
    var params = qs.parse(req.url.substring(2));

    // 向前台写cookie
    res.writeHead(200, {
        'Set-Cookie': 'l=a123456;Path=/;Domain=www.domain2.com;HttpOnly'   // HttpOnly:脚本无法读取
    });

    res.write(JSON.stringify(params));
    res.end();
});

server.listen('8080');
console.log('Server is running at port 8080...');

八、 Nodejs中间件代理跨域

node中间件实现跨域代理,原理大致与nginx相同,都是通过启一个代理服务器,实现数据的转发,也可以通过设置cookieDomainRewrite参数修改响应头中cookie中域名,实现当前域的cookie写入,方便接口登录认证。

1、 非vue框架的跨域(2次跨域)

利用node + express + http-proxy-middleware搭建一个proxy服务器。

1.)前端代码示例:

var xhr = new XMLHttpRequest();

// 前端开关:浏览器是否读写cookie
xhr.withCredentials = true;

// 访问http-proxy-middleware代理服务器
xhr.open('get', 'http://www.domain1.com:3000/login?user=admin', true);
xhr.send();

2.)中间件服务器:

var express = require('express');
var proxy = require('http-proxy-middleware');
var app = express();

app.use('/', proxy({
    // 代理跨域目标接口
    target: 'http://www.domain2.com:8080',
    changeOrigin: true,

    // 修改响应头信息,实现跨域并允许带cookie
    onProxyRes: function(proxyRes, req, res) {
        res.header('Access-Control-Allow-Origin', 'http://www.domain1.com');
        res.header('Access-Control-Allow-Credentials', 'true');
    },

    // 修改响应信息中的cookie域名
    cookieDomainRewrite: 'www.domain1.com'  // 可以为false,表示不修改
}));

app.listen(3000);
console.log('Proxy server is listen at port 3000...');

3.)Nodejs后台同(六:nginx)

2、 vue框架的跨域(1次跨域)

利用node + webpack + webpack-dev-server代理接口跨域。在开发环境下,由于vue渲染服务和接口代理服务都是webpack-dev-server同一个,所以页面与代理接口之间不再跨域,无须设置headers跨域信息了。

webpack.config.js部分配置:

module.exports = {
    entry: {},
    module: {},
    ...
    devServer: {
        historyApiFallback: true,
        proxy: [{
            context: '/login',
            target: 'http://www.domain2.com:8080',  // 代理跨域目标接口
            changeOrigin: true,
            secure: false,  // 当代理某些https服务报错时用
            cookieDomainRewrite: 'www.domain1.com'  // 可以为false,表示不修改
        }],
        noInfo: true
    }
}

九、 WebSocket协议跨域

WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双工通信,同时允许跨域通讯,是server push技术的一种很好的实现。
原生WebSocket API使用起来不太方便,我们使用Socket.io,它很好地封装了webSocket接口,提供了更简单、灵活的接口,也对不支持webSocket的浏览器提供了向下兼容。

1.)前端代码:

<div>user input:<input type="text"></div>
<script data-original="https://cdn.bootcss.com/socket.io/2.2.0/socket.io.js"></script>
<script>
var socket = io('http://www.domain2.com:8080');

// 连接成功处理
socket.on('connect', function() {
    // 监听服务端消息
    socket.on('message', function(msg) {
        console.log('data from server: ---> ' + msg); 
    });

    // 监听服务端关闭
    socket.on('disconnect', function() { 
        console.log('Server socket has closed.'); 
    });
});

document.getElementsByTagName('input')[0].onblur = function() {
    socket.send(this.value);
};
</script>

2.)Nodejs socket后台:

var http = require('http');
var socket = require('socket.io');

// 启http服务
var server = http.createServer(function(req, res) {
    res.writeHead(200, {
        'Content-type': 'text/html'
    });
    res.end();
});

server.listen('8080');
console.log('Server is running at port 8080...');

// 监听socket连接
socket.listen(server).on('connection', function(client) {
    // 接收信息
    client.on('message', function(msg) {
        client.send('hello:' + msg);
        console.log('data from client: ---> ' + msg);
    });

    // 断开处理
    client.on('disconnect', function() {
        console.log('Client socket has closed.'); 
    });
});
查看原文

赞 1402 收藏 2464 评论 59

aisuhua 收藏了文章 · 2018-11-16

一文弄懂Nginx的location匹配

由于团队在进行前后端分离,前端接管了Nginx和node层,在日常的工作中,跟Nginx打交道的时候挺多的。之前对location的匹配规则是一知半解的,为了搞明白location是如何匹配的,查了些资料总结此文。希望能给大家带来帮助。

语法规则

location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }

语法规则很简单,一个location关键字,后面跟着可选的修饰符,后面是要匹配的字符,花括号中是要执行的操作。

修饰符

  • = 表示精确匹配。只有请求的url路径与后面的字符串完全相等时,才会命中。
  • ~ 表示该规则是使用正则定义的,区分大小写。
  • ~* 表示该规则是使用正则定义的,不区分大小写。
  • ^~ 表示如果该符号后面的字符是最佳匹配,采用该规则,不再进行后续的查找。

匹配过程

对请求的url序列化。例如,对%xx等字符进行解码,去除url中多个相连的/,解析url中的...等。这一步是匹配的前置工作。

location有两种表示形式,一种是使用前缀字符,一种是使用正则。如果是正则的话,前面有~~*修饰符。

具体的匹配过程如下:

首先先检查使用前缀字符定义的location,选择最长匹配的项并记录下来。

如果找到了精确匹配的location,也就是使用了=修饰符的location,结束查找,使用它的配置。

然后按顺序查找使用正则定义的location,如果匹配则停止查找,使用它定义的配置。

如果没有匹配的正则location,则使用前面记录的最长匹配前缀字符location。

基于以上的匹配过程,我们可以得到以下两点启示:

  1. 使用正则定义的location在配置文件中出现的顺序很重要。因为找到第一个匹配的正则后,查找就停止了,后面定义的正则就是再匹配也没有机会了。
  2. 使用精确匹配可以提高查找的速度。例如经常请求/的话,可以使用=来定义location。

示例

接下来我们以一个例子来具体说明一下匹配过程。

假如我们有下面的一段配置文件:

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /user/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

请求/精准匹配A,不再往下查找。

请求/index.html匹配B。首先查找匹配的前缀字符,找到最长匹配是配置B,接着又按照顺序查找匹配的正则。结果没有找到,因此使用先前标记的最长匹配,即配置B。

请求/user/index.html匹配C。首先找到最长匹配C,由于后面没有匹配的正则,所以使用最长匹配C。
请求/user/1.jpg匹配E。首先进行前缀字符的查找,找到最长匹配项C,继续进行正则查找,找到匹配项E。因此使用E。

请求/images/1.jpg匹配D。首先进行前缀字符的查找,找到最长匹配D。但是,特殊的是它使用了^~修饰符,不再进行接下来的正则的匹配查找,因此使用D。这里,如果没有前面的修饰符,其实最终的匹配是E。大家可以想一想为什么。

请求/documents/about.html匹配B。因为B表示任何以/开头的URL都匹配。在上面的配置中,只有B能满足,所以匹配B。

location @name的用法

@用来定义一个命名location。主要用于内部重定向,不能用来处理正常的请求。其用法如下:

location / {
    try_files $uri $uri/ @custom
}
location @custom {
    # ...do something
}

上例中,当尝试访问url找不到对应的文件就重定向到我们自定义的命名location(此处为custom)。

值得注意的是,命名location中不能再嵌套其它的命名location

URL尾部的/需不需要

关于URL尾部的/有三点也需要说明一下。第一点与location配置有关,其他两点无关。

  1. location中的字符有没有/都没有影响。也就是说/user//user是一样的。
  2. 如果URL结构是https://domain.com/的形式,尾部有没有/都不会造成重定向。因为浏览器在发起请求的时候,默认加上了/。虽然很多浏览器在地址栏里也不会显示/。这一点,可以访问baidu验证一下。
  3. 如果URL的结构是https://domain.com/some-dir/。尾部如果缺少/将导致重定向。因为根据约定,URL尾部的/表示目录,没有/表示文件。所以访问/some-dir/时,服务器会自动去该目录下找对应的默认文件。如果访问/some-dir的话,服务器会先去找some-dir文件,找不到的话会将some-dir当成目录,重定向到/some-dir/,去该目录下找默认文件。可以去测试一下你的网站是不是这样的。

总结

location的配置有两种形式,前缀字符和正则。查找匹配的时候,先查找前缀字符,选择最长匹配项,再查找正则。正则的优先级高于前缀字符。

正则的查找是按照在配置文件中的顺序进行的。因此正则的顺序很重要,建议越精细的放的越靠前。

使用=精准匹配可以加快查找的顺序,如果根域名经常被访问的话建议使用=

查看原文

aisuhua 发布了文章 · 2017-06-08

一一四啦

sdfsffsdfsfsfsf
s
fd
sdfsdfsfsfs

查看原文

赞 0 收藏 0 评论 0

aisuhua 发布了文章 · 2017-05-24

XXX学习笔记

操作历史 events

数据结构

例子:同步盘策划书.doc

[
    {
        "id":210,
        "opType":"EDIT",
        "path":"/同步盘策划书.doc",
        "isdir":false,
        "isdel":false,
        "size":17,
        "version":2,
        "srcMachineName":"01acs5wkSoWdODo2sUK-dw",
        "editorNickName":"aisuhua",
        "editorAccount":"1079087531@qq.com",
        "timestamp":1494827907000,
        "isVirus":false
    },
    {
        "id":209,
        "opType":"ADD",
        "path":"/同步盘策划书.doc",
        "isdir":false,
        "isdel":false,
        "size":0,
        "version":1,
        "srcMachineName":"01acs5wkSoWdODo2sUK-dw",
        "editorNickName":"aisuhua",
        "editorAccount":"1079087531@qq.com",
        "timestamp":1494827835000,
        "isVirus":false
    }
]

字段分析

opType 行为类型

行为标识例子说明
增加ADD用户 增加文件 同步盘策划书.doc-
修改EDIT用户 修改文件 同步盘策划书.doc-
重命名RENAME用户 重命名文件 同步盘策划书-初稿.doc(原名 同步盘策划书.doc)-
删除DELETE用户 删除文件 同步盘策划书.doc-
恢复RESTORE用户 恢复文件 无标题文档2文件的历史版本记录中可执行此操作
粉碎PURGE用户 粉碎文件 无标题文档2回收站可执行该操作,不可恢复
移动MOVE用户 移动文件 同步盘策划书.doc(从 temp 到 myfolder)移动文件或重命名文件夹时,会发生此操作

path 文件的完整路径

  • 坚果云中的文件没有ID,或者说它的ID就是文件的完整路径 path

  • 同目录下,文件名一定是唯一的。

  • 通过 path 来查看它的版本信息、判断冲突等等。(会产生有趣的现象)

isdir 是否为目录

文件分类标识
文件file
文件夹directory

version 文件版本

  • 每一次操作就会产生一个新的文件版本,操作与文件版本之间是一对一的关系。

  • 文件的版本是操作后的结果,文件的版本号随每一次操作而递增。

操作

操作说明
撤销撤销当前操作,把文件状态回滚到当前操作所对应版本的上一个版本

历史版本

数据结构

例子:文件的版本信息

[
    {
        "version":3,
        "opType":"RESTORE",
        "editorNick":"aisuhua",
        "editorAccount":"1079087531@qq.com",
        "mtime":1494828124000,
        "size":17,
        "isDir":false,
        "isDeleted":false,
        "isDelta":false,
        "altPath":null
    },
    {
        "version":2,
        "opType":"EDIT",
        "editorNick":"aisuhua",
        "editorAccount":"1079087531@qq.com",
        "mtime":1494827907000,
        "size":17,
        "isDir":false,
        "isDeleted":false,
        "isDelta":false,
        "altPath":null
    },
    {
        "version":1,
        "opType":"ADD",
        "editorNick":"aisuhua",
        "editorAccount":"1079087531@qq.com",
        "mtime":1494827835000,
        "size":0,
        "isDir":false,
        "isDeleted":false,
        "isDelta":false,
        "altPath":null
    }
]

操作

操作说明
恢复把文件恢复到特定版本所对应的状态
下载下载特定版本的文件

几点特征

  • 文件夹没有历史版本信息,不能将它恢复到指定的版本。

  • 文件的历史版本记录中没有‘重命名’ RENAME 类型的记录。但 RENAME 操作可以在操作历史中看到。

同步文件夹

分类

分类说明
个人同步文件夹同步个人的私有文件
多人协同文件夹多人参与的同步文件夹
  • 同步文件夹被删除后,该文件夹下的所有文件将被永久清空,不可恢复。

文件冲突

冲突发生的过程:

%E5%86%B2%E7%AA%81%E7%A4%BA%E6%84%8F%E5%9B%BE.png

根据版本号判断文件是否冲突,若本地所修改文件的版本号跟服务端不一致,那么就会发生冲突。

参考:如何避免和解决文件冲突

增量更新

%E8%AF%B4%E6%98%8E.jpg

参考:智能增量同步

例子

操作记录

例1:把 folder 重命名为 folder2

clipboard.png ---> clipboard.png

操作记录

clipboard.png

上传过程

上传进度

clipboard.png

网络截图

  • create 创建文件夹

  • upload 上传文件

clipboard.png

clipboard.png

响应内容

{"version":1,"name":"folder4","path":"/folder4"}

clipboard.png

响应内容

{"size":34,"version":1}
查看原文

赞 0 收藏 0 评论 0

aisuhua 关注了问题 · 2017-05-10

解决看《你不知道的javascript》,自己试验了一下书中一段代码,和书中讲解的不一样

fun(); //报错TypeError
var a=true;
if(a){
    function fun() {
        console.log("1");
    }
}else{
    function fun() {
        console.log("2");
    }
}

按书中的说法,由于函数的提升,且不受条件判断控制,应该是输出2的。可是我运行却报错了。

然后我把条件控制去掉,像这样:

    fun();//2
    function fun() {
        console.log("1");
    }
    function fun() {
        console.log("2");
    }

果然,输出了2

然后,我把条件语句加上,在最后执行函数,像这样:

var a=true;
if(a){
    function fun() {
        console.log("1");
    }
}else{
    function fun() {
        console.log("2");
    }
}
fun();//1

输出1

谁能解释一下,第一个输出的原理?以及和书上的不一样,是因为浏览器升级了的缘故吗?

关注 18 回答 6

认证与成就

  • 获得 95 次点赞
  • 获得 25 枚徽章 获得 1 枚金徽章, 获得 10 枚银徽章, 获得 14 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2015-05-13
个人主页被 1.4k 人浏览