如何解决前端跨域问题？

可以使用服务器代理或者在后端设置允许跨域。

现在的项目一般是在后端设置允许跨域，前端在带有允许跨域的情况下，可以像没有跨域一样正常访问。

如果前端单独发布到服务器，也可以在服务器是设置代理，使用代理转发请求。

原文连接： 原文地址

跨域的详细介绍可以参考： 浏览器和服务器实现跨域(CORS)判定的原理 ，这里不多赘述。

1、主要就是客户端向发送了服务端请求，服务器已经能返回数据，但是浏览器不接收

2、在接口里面加上：( 因为request是处理请求，response是返回结果 )

responsesetHeader("Access-Control-Allow-Origin", "");

responsesetHeader("Cache-Control","no-cache"); 

3、如果是使用Spring Boot创建的项目，直接添加 一句注解 到controller和方法就可以了：

@CrossOrigin

其中@CrossOrigin中的2个参数：

origins  ： 允许可访问的域列表

maxAge ：准备响应前的缓存持续的最大时间（以秒为单位）。

在这个例子中，对于retrieve()和remove()处理方法都启用了跨域支持，还可以看到如何使用@CrossOrigin属性定制CORS配置。如果同时使用controller和方法级别的CORS配置，Spring将合并两个注释属性以创建合并的CORS配置。

4、如果您正在使用Spring Security，请确保在Spring安全级别启用CORS，并允许它利用Spring MVC级别定义的配置。

二、全局CORS配置

　除了细粒度、基于注释的配置之外，您还可能需要定义一些全局CORS配置。这类似于使用筛选器，但可以声明为Spring MVC并结合细粒度@CrossOrigin配置。默认情况下，所有origins and GET, HEAD and POST methods是允许的。

JavaConfig

使整个应用程序的CORS简化为：

更多使用请看原文连接和官方文档

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

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

wwwjdcom/item

wwwjdcom/goods

跨域不一定会有跨域问题。

因为跨域问题是浏览器对于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：

结构：

放到Application下即可。

454重启测试：

访问正常：

webview其实就是一个浏览器，而是否允许跨域，是由你访问的服务器控制的(默认不允许)，如果是nginx，配置如下： http { add_header Access-Control-Allow-Origin ; add_header Access-Control-Allow-Headers X-Requested-With; add_header Access-Control-Allow-Methods GET,POST,OPTIONS; } 其实就是在Http响应头中加了点东西，其他的服务器也类似这样

服务端的解决方案的基本原理就是，由客户端将请求发给本域服务器，再由本域服务器的代理来请求数据并将响应返回给客户端。

最常用的服务器解决方案就是利用web服务器本身提供的proxy功能，如apache和lighttpd的mod_proxy模块。在百度内

部，transmit的分流功能也可以解决部分跨域问题。但这些方法都有一定的局限性，鉴于安全性等问题的考虑，space这边最后开发了一个专门用于处

理跨域请求代理服务的spproxy模块，用于彻底解决js跨域问题。

下面我们将以空间的开放平台为例，简单介绍下如何通过apache的mod_proxy、transmit的分流以及space的spproxy模块来解

决该跨域问题，并简单介绍下spproxy的一些特性、缺点及下一步的改进计划。

空间在展现每个UWA开放模块之前都必须请求该模块的xml源代码以进行解析，每个模块的源代码文件都是存放在act域下的/ow/uwa目录下，那么在

用户空间首页（hi域）中请求该xml文件时就会存在js跨域问题。要解决该问题，只能让js向hi域的web服务器请求xml文件，而hi域web服务

器则通过一定的代理机制（如mod_proxy、transmit分流、spproxy）向act域的web服务器请求文件