Rain is falling all around
it falls on field and tree
it rains on the umbrella here
And on the ships at sea
跨域问题
1. CSRF
CSRF(Cross-site request forgery)，跨域请求伪造，攻击者通过伪造用户的浏览器的请求，向访问一个用户自己曾经认证访问过的网站发送出去，使目标网站接收并误以为是用户的真实操作而去执行命令。常用于盗取账号、转账、发送虚假消息等。攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站能够确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操作行为。
一个经典的案例：用户 A 在邮箱中收到了一封匿名邮件，里面带了一个链接。当用户点击这个链接时，链接就会以参数的形式把邮箱网站的认证凭据（Cookie)发送给了攻击者网站。于是，攻击者网站成功拿到凭证后就能冒充用户给其他人发生邮件。
这样的案例也发生在其他的一些博客，论坛等服务上。例如知乎，他解决的方法是不能直接在网页上跳转，而是需要用户去复制链接，再通过浏览器地址栏进行访问，这样就保证链接拿不到源网页上的东西了。
解决跨域请求伪造的方法还有很多，这里不做扩展，只提一种比较古老的方式，禁止跨域访问。
2. 什么是跨域？
浏览器为了防止 CSRF，提供了一个最核心最基本的安全功能——同源策略。同源（指在同一个域），就是两个页面具有相同的协议（protocol），主机（host），端口号（port）。而跨域就是请求方和发送方在不同的域上。
为什么说禁止跨域是一种比较古老的方式？因为在上古时期的互联网架构，基本都是把前端和后端都是搭在同一个网站上，但如今的架构，前后端分离和分布式服务越发成为主流。浏览器的同源策略也越来越成为鸡肋。
3. 如何解决跨域？
并不是所有的请求都会出现跨域问题，对于一些简单的请求，如 <img src=>，<link href=>，<script src=> 之类的请求，浏览器并不会触发同源策略。而对于其他的复杂请求，如 POST，DELETE 等，才会触发。
浏览器触发同源策略后，会在请求的报文发送前发送一个 method 为 OPTIONS 报文，该报文主要是获取服务器的基本信息，例如支持的请求方式，是否支持跨域等。所以，我们为了支持跨域，一般会在服务端的响应报文上增加 Access-Control-Allow-Origin 这类的响应头。
于是，当浏览器拿到带有支持跨域的响应报文后，才会发送实际的报文，否则就直接抛出跨域错误。
当然，除了由后端去解决跨域外，我们还可以通过 jsonp 等前端的方式去解决跨域，jsonp 解决的原理是通过 <script> 标签把请求转化为简单请求，绕过同源策略，所以不是很推荐。
参考文献：