1. 背景介绍

因为平台采用前后分离的架构来设计，前后端分开部署，部署的域名或者端口不同会导致前端访问后端时存在跨域问题，针对跨域问题比较常见的处理方案有以下几种：

1. CORS：后端配置CORS，允许任何域或者指定域能访问后端服务；

2. 反向代理：通过反向代理让前后端处于同一个域；

3. JSONP：在前端访问后端时通过JSONP解决跨域问题。

以上方案中JSONP的方案对代码逻辑的侵入性太强，不推荐使用。

反向代理需要在部署时通过配置让前后端应用/服务处于同一个域，但是会增加系统部署的配置复杂度。

CORS通过在后端做通用配置解决跨域问题，没有额外配置，是比较推荐的方式，CORS又有两种模式，一种是允许所有来源跨域访问，另一种是允许指定来源的请求跨域访问，前者对于开发环境、测试环境、生产环境都没有配置差异，后者需要按照不同环境分别配置允许跨域的来源域，所以平台默认是按照CORS允许所有来源跨域访问的策略来配置的。

但是这种默认允许所有来源跨域的策略会导致系统有被XSS攻击的风险，下面介绍如何在平台中配置指定来源的CORS策略、反向代理策略。

2. 解决方案

以下两种方案都能解决这个问题，根据系统的部署情况选择一种方案。

2.1 允许指定来源的CORS策略

在如下代码位置配置允许跨域访问的域（多个域可以分别添加），则该域名的前端就可以跨域访问该后端服务了。

2.2 反向代理策略

2.2.1 关闭CORS

如下图所示，首先关闭CORS跨域访问策略。

此时前端访问后端服务时会抛出跨域错误。

2.2.2 Nginx配置反向代理

如下图所示，在Nginx中对每个后端微服务的地址配置反向代理，将请求前端的以/form,/portal,/runtime,/model,/uc开头的请求分别代理到真实的后端地址上去。特别注意这里做了一个地址rewrite，需要在访问时各自追加一个用于识别的服务名，如下图红色框圈出的部分。

2.2.3 前端配置文件中修改后端地址

修改前端的sso.js（或config.js）中配置的后端地址，首先后端地址的域名/ip和端口需要修改为Nginx的域名/ip和端口，其次后端的微服务需要追加反向代理中配置的识别服务名，如下图红色框圈出的部分。

完成以上配置以后，访问系统前后端时使用的是相同的域名和端口，自然也就不存在跨域问题了。