Cross-domain and common solutions

Contact with the front end of a few months, and today I know and talk to the front cross-domain solutions, in fact, before I cross-domain and there is no concept
just heard of this infamous word until the day I met him

What is cross-domain

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。如果两个页面的协议，端口（如果有指定）和主机都相同，则两个页面具有相同的源。我们也可以把它称为“协议/主机/端口 tuple”，或简单地叫做“tuple". ("tuple" ，“元”，是指一些事物组合在一起形成一个整体，比如（1，2）叫二元，（1，2，3）叫三元)。(mdn)

This passage from the top to the MDN, in my opinion anyway, so a large section of dry (gou) Net (pi) Lee (bu) down (tong), then it is very official,

To put it plainly cross-domain means that the host name (domain name), protocol, port number, as long as there is one different, just a different domain, then this time you go cross-domain request, then it will happen

In short what is a kind of browser called the same-origin policy restrictions engaged in things

Origin policy restrictions

When talking about a request is sent to a header Origin the requested address
is then returned to the requestor requested address a Access-Control-Allow-Origin response header, * or if the value corresponding to the site and the Origin, then You may request, if the cross-domain will not correspond

Midway visit the case of same-origin policy restrictions I think this thing is mainly devoted to the request, if not, if you entered a need to visit the site after you log in is complete, the browser save your cookie, and you do not quit other malicious Web site, the malicious site can steal your login information to log in directly to your account
Another is the same-origin policy limits dom query instance, we used in the project through the iframe tag, he can be embedded in an html page to the current page, if a Web site to another site that you trust by iframe embed into their own website, then you enter everything will be crystal clear look at the people, with the same origin policy, then generally requires a proxy to another domain name or whitelist, html introduced to the domain name,

It can be said that same-origin policy restrictions to a basic user protection

url composition (Uniform Resource Locator)

All along, since I contacted the front, and I just kept url to deal with, but I had all this stuff tube called a domain name,
it is embarrassing,
url Chinese called the Uniform Resource Locator, is a resource on the Internet address, a complete look at the main url and components

协议部分，比较常见的有http https ftp 等
域名部分，比如说www.baidu.com 这一块，也可以用服务器的ip作为域名使用
端口，可以不在浏览器中输入，不输入的时候浏览器默认的端口是80
目录部分，从域名后边以/开始以/结束，就好比我们电脑里边文件路径
文件名部分，从域名到路径，然后同理后边的是文件命名部分，比如说xxx.html，也可以不写这个文件命名，不写的时候会使用你的服务器设置的默认的文件命名
锚部分从#开始，#代表页面中的一个位置，右边的字符就是这个位置的标识符，如果页面中有相对应的锚点的或者对应的id的话，浏览器会自动根据锚后边的字符串把可视视图定位到页面的锚点位置
（这个锚部分，用处非常多，到时候单独整理一盘博客）
参数部分从？开始，想必大家之前都见过有些网站的连接后边跟着一些参数，这些参数可以传给服务端，而且这一部分允许有多个参数，可以用&作为分隔符

跨域的几种常用解决方法

script标签，浏览器禁止了跨域的请求访问，但是可以引入其他域的script脚本，并能使用其中的方法，常用的浏览器可以通过load事件判断script是否加载完毕，ie是通过readystatechange属性
postMessage ，这是html5新加的一个新特性，跨文档消息传输Cross Document Messaging。
- window.postMessage()方法可以安全的实现跨域通信，当方法被调用的时候，会在所有页面的脚本执行完毕之后，向目标窗口发送一个messageEvent的一个消息
- otherWindow.postMessage(message, targetOrigin, [transfer]);
- otherWindow
  其他窗口的一个引用，比如iframe的contentWindow属性、执行window.open返回的窗口对象、或者是命名过或数值索引的window.frames。
- message
  将要发送到其他 window的数据。
- targetOrigin
  通过窗口的origin属性来指定哪些窗口能接收到消息事件，其值可以是字符串"星号"（表示无限制）或者一个URI。在发送消息的时候，如果目标窗口的协议、主机地址或端口这三者的任意一项不匹配targetOrigin提供的值，那么消息就不会被发送；只有三者完全匹配，消息才会被发送。
- transfer 可选
  是一串和message 同时传递的 Transferable 对象. 这些对象的所有权将被转移给消息的接收方，而发送一方将不再保有所有权。

在接收的window窗口下边可以增加一个监听

window.addEventListener("message", receiveMessage, false);

function receiveMessage(event)
{
  //回调
}

message对象有四个属性

data是第一个传的参数
origin 表示调用 postMessage 时消息发送方窗口的 origin . 包含了协议，域名和端口
source属性发送消息的窗口对象的引用
JsonP跨域

上边说了script方法其实这个可以说成是一种，另外补充下比如img link等都具有跨域访问的能力
jsonp其实使用这个特性来实现跨域的，在jsonp里边可以定义回调函数，jsonp并不能替代请求，记得有一次微信公众号获取token跨域，jsonp并不能达到相应的效果，感觉jsonp 就是把script标签给封装了一下

CORS访问验证

W3C推荐了一种跨域的访问验证的机制，即CORS（Cross-Origin Resource Sharing 跨源资源共享）。这种机制让Web应用服务器能支持跨站访问控制，使跨站数据传输更加安全，减轻跨域HTTP请求的风险。

CORS验证机制需要客户端和服务端协同处理

现在的各主流的浏览器都会对动态的跨域请求进行特殊的验证处理。验证处理分为简单请求验证处理和预先请求验证处理。

简单请求
当请求的方法是 GET HEAD POST 且请求头的Content-Type是
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain

之一的时候，浏览器会直接发送跨域请求，并在请求头中携带访问地址的header，
当服务端接收到请求之后，会根据自己的跨域规则，通过Access-Control-Allow-Origin和Access-Control-Allow-Methods响应头，来返回验证结果。

如果验证失败则不会返回资源

预先请求

与简单请求对应的，上述的六个条件，只要有一条不符合，浏览器在接收到请求的时候并不会立即执行请求的代码，而是会先发送一个option请求，用于访问服务器是否符合规范

正常来讲我们发送请求，比如post请求的时候，浏览器也会默认给我们加上一个options请求，他的主要用途就是获取服务器支持的http请求房和，和判断安全，
如果验证成功则会发送需要执行的请求，如果验证失败的时候则会返回一个403的状态

以上方法基本上就可以应对大部分的跨域的需求了，还有一些其他的方法比如说document.domain+iframe

如果是都在一个主源里边的话可以用一下，对于不同的源是无能为力的，沾个例子

//www.a.com上的a.html
document.domain = 'a.com';
var ifr = document.createElement('iframe');
ifr.src = 'http://script.a.com/b.html';
ifr.style.display = 'none';
document.body.appendChild(ifr);
ifr.onload = function(){
    var doc = ifr.contentDocument || ifr.contentWindow.document;
    // 在这里操纵b.html
    alert(doc.getElementsByTagName("h1")[0].childNodes[0].nodeValue);
};


//script.a.com上的b.html

document.domain = 'a.com';

比如上边这个www.a.com和script.a.com 他们的js是可以互通的，然后说明一下就是我们在日常用经常看到的www开头的域名其实是二级域名
这里例子里边a.com才是主域名

以上是我对跨域和常用的解决方法的一些认知，有不足之处请多批评，我要去写bug了