前后端分离,spring boot跨域问题

标签: 后端 分离 spring | 发表时间:2018-09-23 23:15 | 作者:ninghq
出处:http://www.iteye.com
跨域:浏览器同源策略
1995年,同源政策由 Netscape 公司引入浏览器。目前,所有浏览器都实行这个政策。
最初,它的含义是指,A网页设置的 Cookie,B网页不能打开,除非这两个网页"同源"。所谓"同源"指的是"三个相同"
协议相同/域名相同/端口相同
一句话:浏览器从一个域名的网页去请求另一个域名的资源时,域名、端口、协议任一不同,都是跨域
浏览器控制台跨域提示:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
解决方法
1)JSONP
2)Http响应头配置允许跨域(通过cors协议解决跨域问题)
 
Cors协议:H5中的新特性:Cross-Origin Resource Sharing(跨域资源共享)。通过它,我们的开发者(主要指后端开发者)可以决定资源是否能被跨域访问。
cors是一个w3c标准,它允许浏览器(目前ie8以下还不能被支持)像我们不同源的服务器发出xmlHttpRequest请求,我们可以继续使用ajax进行请求访问。
具体关于cors协议的文章 ,可以参考http://www.ruanyifeng.com/blog/2016/04/cors.html 这篇文章
第一步:nginx层配置(可以参考https://www.cnblogs.com/hawk-whu/p/6725699.html)
server{
listen 8099;
server_name wdm.test.cn;
location / {
  // 没有配置OPTIONS的话,浏览器如果是自动识别协议(http or https),那么浏览器的自动OPTIONS请求会返回不能跨域
  if ($request_method = OPTIONS ) {
    add_header Access-Control-Allow-Origin "$http_origin";
    add_header Access-Control-Allow-Methods "POST, GET, PUT, OPTIONS, DELETE";
    add_header Access-Control-Max-Age "3600";
    add_header Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept, Authorization";
    add_header Access-Control-Allow-Credentials "true";
    add_header Content-Length 0;
    add_header Content-Type text/plain;
    return 200;
  }
  add_header 'Access-Control-Allow-Origin' '$http_origin';
  add_header 'Access-Control-Allow-Credentials' 'true';
  add_header 'Access-Control-Allow-Methods' 'GET, PUT, POST, DELETE, OPTIONS';
  add_header 'Access-Control-Allow-Headers' 'Content-Type,*';
  proxy_pass http://127.0.0.1:8080;
  }
}
  第二步:程序代码中处理
SpringBoot自带配置
@Configuration
public class Cors extends WebMvcConfigurerAdapter {
@Override
 public void addCorsMappings(CorsRegistry registry) {
	 registry.addMapping("/**")
		 .allowedOrigins("*")
		 .allowedMethods("GET", "POST", "PUT", "OPTIONS", "DELETE", "PATCH")
		 .allowCredentials(true).maxAge(3600);
	}

}
 如果想做到更细致也可以使用@CrossOrigin这个注解在controller类中使用。
@CrossOrigin(origins = "http://192.168.1.97:8080", maxAge = 3600)
@RequestMapping("rest_index")
@RestController
public class IndexController{}
 (注意点:假如接口报错,则跨域配置不生效)


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [后端 分离 spring] 推荐:

前后端分离,spring boot跨域问题

- - 编程语言 - ITeye博客
1995年,同源政策由 Netscape 公司引入浏览器. 目前,所有浏览器都实行这个政策. 最初,它的含义是指,A网页设置的 Cookie,B网页不能打开,除非这两个网页"同源". 所谓"同源"指的是"三个相同". 协议相同/域名相同/端口相同. 一句话:浏览器从一个域名的网页去请求另一个域名的资源时,域名、端口、协议任一不同,都是跨域.

spring +mybatis读写分离

- - 编程语言 - ITeye博客
一、配置定义数据库连接属性. .     .     .     .     .         . .

spring实现数据库读写分离

- - 行业应用 - ITeye博客
现在大型的电子商务系统,在数据库层面大都采用读写分离技术,就是一个Master数据库,多个Slave数据库. Master库负责数据更新和 实时数据查询,Slave库当然负责非实时数据查询. 因为在实际的应用中,数据库都是读多写少(读取数据的频率高,更新数据的频率相对较少),而读取数据 通常耗时比较长,占用数据库服务器的CPU较多,从而影响用户体验.

使用Spring实现读写分离

- - 编程语言 - ITeye博客
 1. 使用 背景. 我们一般应用对数据库而言都是“读多写少”,也就说对数据库读取数据的压力比较大,有一个思路就是说采用数据库集群的方案,. 其中一个是主库,负责写入数据,我们称之为:写库;. 其它都是从库,负责读取数据,我们称之为:读库;. 解决读写分离的方案有两种:应用层解决和中间件解决. 2.1.  应用层解决:.

Spring中@Transactional与读写分离

- - 编程语言 - ITeye博客
    本文主要介绍如何使用Spring @Transactional基于JDBC Replication协议便捷的实现数据库的读写分离.     1)Spring 4.x + 环境.     3)tomcat-jdbc-pool连接池.     4)spring @Transaction使用与JDBC Replcation协议.

在应用层通过spring解决数据库读写分离

- - CSDN博客推荐文章
如何配置mysql数据库的主从. 单机配置mysql主从: http://my.oschina.net/god/blog/496. 常见的解决数据库读写分离有两种方案. http://neoremind.net/2011/06/spring实现数据库读写分离. 目前的一些解决方案需要在程序中手动指定数据源,比较麻烦,后边我会通过AOP思想来解决这个问题.

Spring 配置多数据源实现数据库读写分离

- - 企业架构 - ITeye博客
现在大型的电子商务系统,在数据库层面大都采用读写分离技术,就是一个Master数据库,多个Slave数据库. Master库负责数据更新和实时数据查询,Slave库当然负责非实时数据查询. 因为在实际的应用中,数据库都是读多写少(读取数据的频率高,更新数据的频率相对较少),而读取数据通常耗时比较长,占用数据库服务器的CPU较多,从而影响用户体验.

Spring + JPA实现数据库读写分离

- - 深入一点,你会更加快乐
    本文展示了如何在Spring环境中使用JPA实现dataSource的读写分离(本文没有使用JTA事务),这个东西看起来简单,其实实现起来比较蹩脚,与JDBC有很大区别.     1)使用Spring中的AbstractRoutingDataSource,辅助程序在运行时选择合适的dataSource.

前后端分离了,然后呢?

- - ITeye资讯频道
前后端分离已经是业界所共识的一种开发/部署模式了. 关于前后端开发的另一个讨论可以参考这里. 即使通过API来解耦前端和后端开发过程,前后端通过RESTFul的接口来通信,前端的静态内容和后端的动态计算分别开发,分别部署,集成仍然是一个绕不开的问题 — 前端/后端的应用都可以独立的运行,但是集成起来却不工作.

前后端分离的优缺点

- - Web前端 - ITeye博客
WEB 前后端分离三个最大的优点在于:1:最大的好处就是前端JS可以做很大部分的数据处理工作,对服务器的压力减小到最小2:后台错误不会直接反映到前台,错误接秒较为友好3:由于后台是很难去探知前台页面的分布情况,而这又是JS的强项,而JS又是无法独立和服务器进行通讯的. 所以单单用后台去控制整体页面,又或者只靠JS完成效果,都会难度加大,前后台各尽其职可以最大程度的减少开发难度.