什么是跨域 & 跨域的3种解决方案

什么是跨域

所谓同源（即指在同一个域）就是两个页面具有相同的协议（protocol），主机（host）端口号（port）

同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。 同源策略是浏览器安全的基石

同源策略会阻止一个域的 javascript 脚本和另外一个域的内容进行交互。例如办公内外网环境，当我们访问外网一个恶意网站的时候，恶意网站就会利用我们的主机向内网的 url 发送 ajax 请求，破坏或盗取数据

 当一个请求url的协议、域名、端口三者之间任意一个与当前页面url不同即为跨域

当前页面url	被请求页面url	是否跨域	原因
http://www.test.com/	http://www.test.com/index.html	否	同源（协议、域名、端口号相同）
http://www.test.com/	https://www.test.com/index.html	跨域	协议不同（http/https）
http://www.test.com/	http://www.baidu.com/	跨域	主域名不同（test/baidu）
http://www.test.com/	http://blog.test.com/	跨域	子域名不同（www/blog）
http://www.test.com:8080/	http://www.test.com:7001/	跨域	端口号不同（8080/7001）

浏览器的非同源限制以及3种解决思路#

非同源限制

1. 无法读取非同源网页的 Cookie、LocalStorage 和 IndexedDB
2. 无法接触非同源网页的 DOM
3. 无法向非同源地址发送 AJAX 请求，即 XHR 请求

跨域的解决思路 1 —— 避免非同源限制

1. 让浏览器不做限制，指定参数，让浏览器不做校验，但该方法不太合理，因为它需要每个人都去做改动
2. 不要发出 XHR 请求，这样就算是跨域，浏览器也不会有非同源限制，解决方案是 JSONP，通过动态创建一个 script，通过 script 发出请求

跨域的解决思路 2 —— 跨源资源共享方案

1. 根据 W3C 的跨源资源共享方案，在被调用方修改代码，加上字段，告诉浏览器该网站支持跨域

跨域的解决思路 3 —— 隐藏跨域

1. 使用 Nginx 反向代理，在 a 域名里面的的请求地址使用反向代理指向 b 域名，让浏览器以为一直在访问 a 网站，不触发跨域限制

JSONP#

• 普通请求值 XHR，希望得到服务端返回的 content-type 一般是 json
• JSONP 发出的是 script 请求，希望得到的返回是 js 脚本

  Content-Type 是指 http/https 发送信息至服务端时的内容编码类型，在 HTTP 协议消息头中，使用 Content-Type 来表示请求和响应中的媒体类型信息。它用来告诉服务端如何处理请求的数据，以及告诉客户端（一般是浏览器）如何解析响应的数据，比如显示图片，解析并展示 html 等等。
  
      并不是请求或响应独有的参数

  什么是跨域 & 跨域的3种解决方案

  所谓同源（即指在同一个域）就是两个页面具有相同的协议（protocol），主机（host）端口号（port）

  同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。 同源策略是浏览器安全的基石

  同源策略会阻止一个域的 javascript 脚本和另外一个域的内容进行交互。例如办公内外网环境，当我们访问外网一个恶意网站的时候，恶意网站就会利用我们的主机向内网的 url 发送 ajax 请求，破坏或盗取数据

  浏览器的非同源限制以及3种解决思路#

  非同源限制

  1. 无法读取非同源网页的 Cookie、LocalStorage 和 IndexedDB
  2. 无法接触非同源网页的 DOM
  3. 无法向非同源地址发送 AJAX 请求，即 XHR 请求

  跨域的解决思路 1 —— 避免非同源限制

  1. 让浏览器不做限制，指定参数，让浏览器不做校验，但该方法不太合理，因为它需要每个人都去做改动
  2. 不要发出 XHR 请求，这样就算是跨域，浏览器也不会有非同源限制，解决方案是 JSONP，通过动态创建一个 script，通过 script 发出请求

  跨域的解决思路 2 —— 跨源资源共享方案

  1. 根据 W3C 的跨源资源共享方案，在被调用方修改代码，加上字段，告诉浏览器该网站支持跨域

  跨域的解决思路 3 —— 隐藏跨域

  1. 使用 Nginx 反向代理，在 a 域名里面的的请求地址使用反向代理指向 b 域名，让浏览器以为一直在访问 a 网站，不触发跨域限制

  JSONP#

  • 普通请求值 XHR，希望得到服务端返回的 content-type 一般是 json
  • JSONP 发出的是 script 请求，希望得到的返回是 js 脚本

  Content-Type 是指 http/https 发送信息至服务端时的内容编码类型，在 HTTP 协议消息头中，使用 Content-Type 来表示请求和响应中的媒体类型信息。它用来告诉服务端如何处理请求的数据，以及告诉客户端（一般是浏览器）如何解析响应的数据，比如显示图片，解析并展示 html 等等。

  并不是请求或响应独有的参数

  JSONP 原理#

  以 JQuery 为例，发送 ajax 请求的时候，设置dataType:"jsonp"，将使用 JSONP 方式调用函数，函数的 url 变为myurl?callback=e5bbttt的形式，e5bbttt 就是一个临时方法名，后端会根据callback的值返回一个 js 脚本，如

  <script>
   e5bbttt({"a":"aaa","b":"bbb"});
  </script>

  Query 会提前根据 ajax 中 success 的内容生成一个临时函数，名字就是 xxx

  $.ajax({
  // 其他省略
    dataType:"jsonp",
    success:function(data){
    console.log(data.a);
    console.log(data.b);
  },
  jsonp:"e5bbttt"
  })
  //JQuery 生成的临时函数
  function e5bbttt(data){
  ajaxObject.success(data);
  }

  服务端返回给客户端的e5bbttt({"a":"aaa","b":"bbb"});，相当于立即调用了 JQuery 生成的e5bbttt函数，用完这个函数就销毁了

  JSONP 也算是一个约定俗成的“协议”，callback 是约定俗成的作为定义临时函数名的参数。如果想自定义这个参数名，需要在 ajax 中用 jsonp 属性定义。

   JSONP 的弊端#

  1. 需要服务器改动代码
  2. 只支持 GET 请求
  3. 发送的不是 xhr 请求
  4. 不安全

  后端解决跨域

  在服务器端解决跨域有2种解决思路

  • 在被调用后端应用解决：在响应头增加指定字段，告诉浏览器允许调用。这种解决方案的请求是直接从浏览器发送给后端服务器，在浏览器上会看到 b.com 的 url
  • 在前端服务器解决：这是隐藏跨域的解决方案。这种跨域请求不是直接从浏览器发送的，而是从中间的 http 服务器（前端应用所在服务器）转发过去的，在浏览器中看到的还是 a.com 的 url，所以不会认为是跨域。但是该到 b.com 的请求还是会到 b.com

  跨域原理及后端解决思路#

  依据浏览器同源策略，非同源脚本不可操作其他源下面的对象。想要操作其他源下的对象就需要跨域。综上所述，在同源策略的限制下，非同源的网站之间不能发送 ajax 请求。如有需要，可通过降域或其他技术实现。

  为了解决浏览器跨域问题，W3C 提出了跨源资源共享方案，即 CORS(Cross-Origin Resource Sharing)。

  CORS 可以在不破坏即有规则的情况下，通过后端服务器实现 CORS 接口，就可以实现跨域通信。

  CORS 将请求分为两类：简单请求和非简单请求，分别对跨域通信提供了支持。

  简单请求#

  1. 在 CORS 出现前，发送 HTTP 请求时在头信息中不能包含任何自定义字段，且 HTTP 头信息不超过以下几个字段：
     1. Accept
     2. Accept-Language
     3. Content-Language
     4. Last-Event-ID
     5. Content-Type 仅为这3种
        • application/x-www-form-urlencoded
        • multipart/form-data
        • text/plain
  2. 一个简单请求：请求方法是 GET HEAD POST 且满足条件1

     GET /test HTTP/1.1
     Accept: */*
     Accept-Encoding: gzip, deflate, sdch, br
     Origin: http://www.test.com
     Host: www.test.com

     对于简单请求，CORS 的策略是请求时在请求头中增加一个 Origin 字段，表示请求发出的域。服务器收到请求后，根据该字段判断是否允许该请求访问。

     • 如果允许，则在 HTTP 头信息中添加 Access-Control-Allow-Origin 字段，并返回正确的结果
     • 如果不允许，则不添加 Access-Control-Allow-Origin 字段

     除了上面提到的 Access-Control-Allow-Origin，还有几个字段用于描述 CORS 返回结果

     • Access-Control-Allow-Credentials：可选，用户是否可以发送、处理cookie
     • Access-Control-Expose-Headers：可选，可以让用户拿到的字段。有几个字段无论是否允许跨域都可以拿到的：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma

  非简单请求#

• 一般是发送 JSON 格式的 ajax 请求，或带有自定义头的请求

  对于非简单请求的跨源请求，浏览器会在真实请求发出前，增加一次 OPTION 请求，称为预检请求(preflightrequest)。预检请求将真实请求的信息，包括请求方法、自定义头字段、源信息添加到 HTTP 头信息字段中，询问服务器是否允许这样的操作

  例如一个 GET 请求的预检请求，包含一个自定义参数 X-Custom-Header

  OPTIONS /test HTTP/1.1
  Origin: http://www.test.com
  Access-Control-Request-Method: GET // 请求使用的 HTTP 方法
  Access-Control-Request-Headers: X-Custom-Header // 请求中包含的自定义头字段
  Host: www.test.com

  服务器收到请求时，需要分别对 Origin、Access-Control-Request-Method、Access-Control-Request-Headers 进行验证，验证通过后，会在返回 HTTP 头信息中添加：

  HTTP/1.1 200 OK
  Access-Control-Allow-Origin: http://www.test.com // 允许的域
  Access-Control-Allow-Methods: GET, POST, PUT, DELETE // 允许的方法
  Access-Control-Allow-Headers: X-Custom-Header // 允许的自定义字段
  Access-Control-Allow-Credentials: true // 是否允许用户发送、处理 cookie
  Access-Control-Max-Age: 172800 // 预检请求的有效期，单位为秒。有效期内，不需要发送预检请求，ps 48小时

  当预检请求通过后，浏览器才会发送真实请求到服务器。这样就实现了跨域资源的请求访问。

  所以后端处理其实处理的就是这次预检请求

• 注意：

  在 Chrome 和 Firefox 中，如果 Access-Control-Allow-Methods 中并未允许 GET/POST/HEAD 请求，但允许跨域了，浏览器还是会允许 GET/POST/HEAD 这些简单请求访问，这时就必须在后台用其他办法禁掉这些 Method

  后端应用处理 - Filter&HttpServletResponse 方法#

  这种方法不会用到 Spring，对 Servlet 也可以使用

  在 web.xml 中配置

  <!-- 跨域 -->
  <filter>
    <filter-name>webFliter</filter-name>
    <filter-class>com.n031.filter.WebFliter</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>webFliter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

  编写 java 类

  import javax.servlet.*;
  import javax.servlet.http.HttpServletResponse;
  import java.io.IOException;
  public class WebFliter implements Filter {
      @Override
    public void init(FilterConfig filterConfig) throws ServletException {
  
      }
     @Override
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest)request;
        HttpServletResponse res = (HttpServletResponse) response;
        // 允许跨域的域名，设置*表示允许所有域名
        String origin = req.getHeader("Origin");
         if ("abcdefg".contains(origin)) {  // 满足指定的条件
           res.addHeader("Access-Control-Allow-Origin", origin);
         }
          res.addHeader("Access-Control-Allow-Origin", "http://www.test.com");
        // 允许跨域的方法，可设置*表示所有
          res.addHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
        // 允许的自定义字段
     String headers = req.getHeader("Access-Control-Request-Headers"); // 获取 request 发来的自定义字段
      res.addHeader("Access-Control-Allow-Headers", headers);
       // 或者
       // res.addHeader("Access-Control-Allow-Headers", "X-Custom-Header");
      // 预检请求的有效期，单位为秒。有效期内，不需要发送预检请求，ps 48小时
       res.addHeader("Access-Control-Max-Age", "172800");
      // 还可以有其他配置...
         chain.doFilter(request, response);
    }
  
  
      @Override
  
      public void destroy() {
  
      }
  
  
  }

  后端应用处理 - Spring 方法#

  Spring 解决跨域的方法很多，感觉就和茴字有五种写法一样。这里列举的并不全。

  先看下原理。说实话虽然搞不懂为什么这么做，但看了下这个类的源码确实是这么写的。

  本质都是构造CorsConfiguration然后委托给DefaultCorsProcessor实现

  public class CorsConfiguration {
      private List<String> allowedOrigins;
      private List<String> allowedMethods;
      private List<String> allowedHeaders;
      private List<String> exposedHeaders;
      private Boolean allowCredentials;
      private Long maxAge;
  
  }

  DefaultCorsProcessor的processRequest处理步骤如下（spring-web 5.1.8-RELEASE）

  1. 判断是否是包含 Origin 字段，不包含就放行，否则继续判断
  2. 判断 Response 的 Header 是否已经包含 Access-Control-Allow-Origin。如果包含，证明已经被处理过了，放行，否则继续判断
  3. 判断是否同源，如果是则放行，否则继续判断
  4. 到此步基本已经得出这是个跨域请求的结论。然后看配置了 CORS 规则
     • 没有配置，且是预检请求，则拒绝该请求（说明该应用禁止跨域）
     • 没有配置，且不是预检请求，跳过跨域处理（有可能导致返回数据被浏览器拦截）
     • 配置了，则根据配置的规则（CorsConfiguration）决定是否放行

  在 Controller 上添加 @CrossOrigin 注解#

  这种方式适合只有一两个 rest 接口需要跨域或者没有网关的情况下，这种处理方式就非常简单，适合在原来基代码基础上修改，影响比较小。