大家好，今天来为大家分享谷歌浏览器 跨域 cors的一些知识点，和谷歌浏览器 跨域解决的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！

本文目录

1. Http 跨域(Cors) 详解
2. 浏览器跨域及其解决方案
3. 【http】什么是cors跨域
4. 使用CORS解决跨域问题

一、Http 跨域(Cors) 详解

1.构成跨域的条件(满足下方任意一个条件则构成跨域)

   domain不同(域名或者ip不同)

  协议不同(http/https)

给大家展示一个请求头和响应头,这是满足跨域的

POST HTTP/1.1

Accept: application/json, text/plain,*/*

Origin:

User-Agent: Mozilla/5.0(iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38(KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1

Content-Type: application/x-www-form-urlencoded

Referer:

Accept-Encoding: gzip, deflate, br

Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7

Cookie: cna=CKV9Ew45tVYCAX1SFKx2d19k; _uab_collina=152896489958250435552525; _umdata=65F7F3A2F63DF020E1473F196945E27DBC990F7BBC00081CD2D29B2B4AD9F1FCC05972083687D762CD43AD3E795C914CD2FEBFBF6205958F64E60BC7B372D87F; Hm_lvt_31d8fd22bdec2e7ab9e5855741f0fac1=1541048271,1541503268,1542598403,1543222019; SESSION=NDllODZlMWQtODk5ZC00MDg3LThiN2ItNGM0MTRlMjZlOTFm

phone=15555555555&password=111111

Vary: Access-Control-Request-Method

Vary: Access-Control-Request-Headers

Access-Control-Allow-Origin:

Access-Control-Allow-Credentials: true

Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Tue, 01-Jan-2019 06:44:30 GMT

Content-Type: application/json;charset=UTF-8

Date: Wed, 02 Jan 2019 06:44:30 GMT

{"data":{"id":2,"name":null,"nickName":"15555555555","email":null}

首先请求头中需要设置,这个是设置跨域的的协议,domain和端口,也就是浏览器地址的栏的根路径

Origin:

服务器获取到这个请求头之后开始进行校验校验成功后,设置响应头

Access-Control-Allow-Origin参数建议不要设置为* 设置为*的话,其他的请求时则不会带上 Cookie

Access-Control-Allow-Origin:

Access-Control-Allow-Credentials: true

将这个响应头设置好返回给浏览器,就达到跨域的效果了

//预检结果缓存时间,也就是上面说到的缓存啦

'Access-Control-Max-Age: 1800'

'Access-Control-Allow-Methods:GET,POST,PUT,POST'

'Access-Control-Allow-Headers:x-requested-with,content-type'

参考链接

二、浏览器跨域及其解决方案

1、什么是跨域跨域的表现解决跨域问题-浏览器设置(不推荐)-前端的非正统解决方式- CORS(跨域资源共享)-配置nginx反向代理

2、跨域出于浏览器的同源策略限制，同源是指协议、域名、端口都一样，同源策略（Sameoriginpolicy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。

3、调用页面时接口数据不返回，控制台中会有红色的报错信息中有类似于 CORS policy关键字。另外，在最新谷歌浏览器中，会有提出类似于loaded over HTTPS此种关键字，均可以考虑为跨域导致。

4、 [图片上传失败...(image-26deed-1651135597111)]

5、 tips:有的时候后台小伙伴使用postman测试好的接口，前端不可以使用，原因就是postman不是浏览器，不会有同源限制，同理移动设备app开发和小程序开发也不会有这个问题。这个不是前端bug，同源限制也不是一个不好的规则。

6、虽然跨域不是一个不好的事情，但是对于前后端分离的web开发来说确实需要解决的，大致的解决方案可分为：

7、直接从根源解决问题，让浏览器安全策略不起作用。这个方法虽然可以解决问题但是不现实。

8、官方正统解决方案， CORS规范允许服务器向浏览器返回一些HTTP Headers，浏览器可以基于这些HTTP Headers来决定是否突破SOP的限制。需要后端配合，浏览器需要什么，接口服务给什么。

9、 nginx是一个高性能的HTTP和反向代理web服务器，nginx用来解决跨域问题的原理与前端非正统解决方式的 proxy的思路是一致的。项目请求接口由nginx服务发出，获取到的数据再经由nginx传递给前端项目，这样前端的请求其实都是由nginx处理的，就没有跨域发生了。

三、【http】什么是cors跨域

1、前端开发中，常常需要进行跨域请求。既然提到跨域，首先我们的知道什么是“同源策略”。

2、同源策略限制从一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的关键的安全机制。

3、如果协议，端口（如果指定了一个）和域名对于两个页面是相同的，则两个页面具有相同的源。

4、同一个源内，资源的访问是很自由的。就跟在自己家中，想开冰箱开冰箱，想干啥干啥。如果你想访问不同源的资源，可就没那么自由了，这就是跨域。

5、关于跨域，常用的JSONP应该都知道。JSONP的原理是什么呢？我们来看看大神贺师俊的解释：

6、很简单，就是利用<script>标签没有跨域限制的“漏洞”（历史遗迹啊）来达到与第三方通讯的目的。当需要通讯时，本站脚本创建一个<script>元素，地址指向第三方的API网址，并提供一个回调函数来接收数据（函数名可约定，或通过地址参数传递）。第三方产生的响应为json数据的包装（故称之为jsonp，即json padding），这样浏览器会调用callback函数，并传递解析后json对象作为参数。本站脚本可在callback函数里处理所传入的数据。

7、可以知道JSONP就是个bug般的存在啊，如果你是一个有洁癖的程序员回想说：这不合理，这部干净。因此我们引出cors。

8、 CORS（跨来源资源共享）是一份浏览器技术的规范，提供了Web服务从不同网域传来沙盒脚本的方法，以避开浏览器的同源策略，是JSONP模式的现代版。

9、 Cross-origin resource sharing(CORS) is a mechanism that allows restricted resources(e.g. fonts) on a web page to be requested from another domain outside the domain from which the first resource was served.

10、这样看来，其实嘛，cors就是一个规范，机制，基于这个规范，不同源之间才可以请求资源。相当于一个江湖规矩，大家都按规矩来嘛不是？不讲规矩？信不信小拳拳捶你。

11、所以呢，要想使用cors跨域访问，你就得讲规矩。下面我们来看看有哪些规矩。

12、跨域资源共享标准（ cross-origin sharing standard）允许在下列场景中使用跨域 HTTP请求：

13、 cors中有个术语叫“简单请求”，若请求满足所有下述条件，则该请求可视为“简单请求”：

14、之所以区分简单请求，是因为cors需要处理一些“非简单请求”，这种特殊处理叫做“预检请求”。大人物来了，总要提前准备准备吧，封路啥的blabla。

15、预检请求的作用是提前获知服务器是否允许该实际请求。“预检请求”的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。

16、一张图可以清晰看到提前发送预检请求的cors请求

四、使用CORS解决跨域问题

跨域是指跨域名的访问，以下情况都属于跨域：

如果域名和端口都相同，但是请求路径不同，不属于跨域，如：

因为跨域问题是浏览器对于ajax请求的一种安全限制：一个页面发起的ajax请求，只能是于当前页同域名的路径，这能有效的阻止跨站攻击。

因此：跨域问题是针对ajax的一种限制。

但是这却给我们的开发带来了不变，而且在实际生成环境中，肯定会有很多台服务器之间交互，地址和端口都可能不同，怎么办？

目前比较常用的跨域解决方案有3种：

我们这里会采用cors的跨域方案。

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。

它允许浏览器向跨源服务器，发出 XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

浏览器会将ajax请求分为两类，其处理方案略有差异：简单请求、特殊请求。

只要同时满足以下两大条件，就属于简单请求。：

（1)请求方法是以下三种方法之一：

（2）HTTP的头信息不超出以下几种字段：

当浏览器发现发现的ajax请求是简单请求时，会在请求头中携带一个字段： Origin.

Origin中会指出当前请求属于哪个域（协议+域名+端口）。服务会根据这个值决定是否允许其跨域。

如果服务器允许跨域，需要在返回的响应头中携带下面信息：

如果跨域请求要想操作cookie，需要满足3个条件：

不符合简单请求的条件，会被浏览器判定为特殊请求,，例如请求方式为PUT。

特殊请求会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的 XMLHttpRequest请求，否则就报错。

与简单请求相比，除了Origin以外，多了两个头：

服务的收到预检请求，如果许可跨域，会发出响应：

除了 Access-Control-Allow-Origin和 Access-Control-Allow-Credentials以外，这里又额外多出3个头：

如果浏览器得到上述响应，则认定为可以跨域，后续就跟简单请求的处理是一样的了。

虽然原理比较复杂，但是前面说过：

事实上，SpringMVC已经帮我们写好了CORS的跨域过滤器：CorsFilter,内部已经实现了刚才所讲的判定逻辑，我们直接用就好了。

在 Application下编写一个配置类，并且注册CorsFilter：

好了，文章到此结束，希望可以帮助到大家。