跨域问题剖析

    我们今天聊一下跨域，以下只是个人理解，如有不对，还请指正。希望这篇文章能帮助大家避开跨域的坑或者解决当下的跨域问题。

    聊到跨域，不由不提浏览器的同源策略。源相同，资源才能访问，这也是保证网络资源安全的一种手段。先考虑一个问题，然后我们看下，什么是源，同源策略检测的是那些内容。

    问题：跨域真的是跨“域”吗？不可否认，多数情况是因为域名不同引起的，有的时候降域也确实能解决问题，但我们也只能降到一级域名。思考：为什么跨域资源共享策略为什么叫cross origin resource sharing呢？域不是domain吗？origin是什么呢？

    我们来一探究竟（个人理解，非官方）：

    域 === document.domain === （服务器名.）域名.后缀。

通常，域在url上的位置

    源 === 来源 === origin === 协议://domain:（端口）

百度为例

    到这里，我们知道，同源策略，检测的是协议，域名，端口号（如果有的话，默认走80）。个人感觉，我们平时所说的“跨域资源共享”，其实称作跨源资源共享更严谨，也许是因为一般协议的检查都会通过，所以更习惯称呼“跨域资源共享”吧。

    跨域资源共享，缩写CORS（全名已在上面提到），专治同源策略导致的请求失败。原理是：用额外的 HTTP 头来告诉浏览器，让运行在一个origin上的Web应用被准许访问服务器上指定的资源。多数情况下大家会意识到，为什么我发get请求可以，post强求没发出去，甚至在发option的时候就报跨域？这里给大家推荐一篇文章，对于cors预检，这里就不赘述了。

特殊的HTTP头部：

Access-Control-Allow-Origin: 接受哪些域名的请求

Access-Control-Allow-Credentials：是否允许携带credentials

Access-Control-Expose-Headers：向请求方暴露那些额外的头部信息

    一般前两个用的比较多。第二个参数提到了credential（认证信息），不得不提起cookie，因为我们常用cookie来做登陆认证，认证不通过，也是访问不到资源的。

cookie来源

    往往在第一次登陆的时候，服务器会给客户端发一个cookie认证信息（就像你第一天入职，公司发你一张工卡），然后，每次请求的时候带着。之所以这么做呢，是因为http是无状态的，w3c设想之初也曾考虑把登陆状态放在服务器，但考虑到客户端的数量，该方案最终被抛弃。

    大概的过程先说这么多，可能很多人会问，cookie怎么携带的？出现跨域问题怎么解决？怎么携带cookie呢，不同的调用方式各不相同，现用现查即可。那，怎么解决跨域问题呢？

    前文中提到降域，也就是直接改document.domain。但这种方法有局限性，只能降到一级域名。另外一种就是通过跨域资源共享，服务器和客户端都做一些处理，一般客户端带着认证信息到服务器，服务器允许访问即可。最后一种是通过jsonp的方式也能解决跨域问题，但这种解决方式本质上是钻了一个空子，script标签和img标签里的静态资源，是不会触发cors验证的，也就不存在跨域。本质上是服务器端返回一段自执行脚本，脚本执行后把结果通过callback返回。