nginx 解决跨域问题嵌入第三方页面

前言

我们自己的系统需要加载第三方系统中的一部分组件。计划的是第三方开发、提供相关接口，我们通过接口获取到数据，然后，再用这些数据在我们系统中吧相关的功能实现了

可惜的是，领导没有协调下来。正规的途径搞不定，那就需要花式整活了

前面也说了，我们走接口拉数据重新渲染，这样的玩法是比较常规的，缺点是需要重新去实现相关模块，还需要对方开放接口。

现在只能走非正常渠道，比如，容易想到的，就是 我们直接把页面嵌入到自己的系统，同时需要对第三方页面的样式，组件进行控制

困难

上面提到的方法，就是在我们自己的系统里，规划一个 iframe，通过 src 属性引入第三方的系统。
这里一个最大的问题，就是跨域。网络上提到的最有可能解决的方案，通过 postMessage跨域，可惜，这个还是需要第三方配合

跨域定义

首先狭义的同源就是指，域名、协议、端口均为相同。
跨域，是指浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器对JavaScript实施的安全限制。

nginx 的特性

反向代理

配置一个 url，用户如果访问这个 url ，就能给代理到真实需要的 url

动静分离

正如字面的意思，动态的资源（需要服务器进行计算）和静态的资源（一般是指 html，css，js，img等静态页面的相关资源）分离开来

尝试实现

因为我们的 A 应用使用了 80 端口，第三方的 B 系统也使用了 80 端口，那就需要加后缀来区分代理到 B 系统，大致的 url 如下

# A 的 url
http://localhost/
# B 加后缀的 url
http://localhost/three-part
# B 的实际 url
http://172.16.1.1/

我们正常访问 localhost 会到 A 系统的首页，访问 172.16.1.1 会访问 B 的首页，如果通过代理的 URL 去访问，nginx 实际上会给代理到 172.16.1.1/three-part，没错，测试的时候，发现吧后缀给带过去了？？ 不排除我不专业，没配置到位，但我测试的效果就是这样

上述配置的思路，就是让两个应用同 ip 同端口，然后 A 应用里 iframe 加载了 B 的首页，那就能通过 js 去操作

很遗憾，那就只有配置成不同的端口了，比如给 B 应用的代理 url 配置为 localhost:81/，这样一来，无法在 A 应用的 iframe 对应的页面里，编写对 B 应用修改的 js 了

最终效果

随着我对 B 应用的 f12，我发现，他们封装了一个 x.min.js ，这个文件登陆的时候会加载，进入首页后也会加载。
那么，骚操作就来了，我直接重写他们的这个 js 文件，吧我需要的逻辑安排在文件的最后面，然后，让页面在加载这个 x.min.js 的时候，去加载我服务器端修改过后的 js 文件，而不是去加载第三方服务器里的 x.min.js

整个流程的示意图如下示：

下面就是我配置好正在用的nginx配置

upstream mir{
    server 10.1.128.58:80;
}
server {
 listen     localhost:8001; # nginx 需要监听的 url及对应的端口
 location =/static/mir.min.js {
  root C:/r9/bin/resources;
 }
 location / {
  # 可以理解为这里用了一个 url 的变量名，这个变量名定义在 upstream 中
  proxy_pass http://mir;
  # 下面几项算是跨域标配，直接抄上就行
  proxy_set_header Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Fonwarded-For $proxy_add_x_forwarded_for;
  if ($request_method = 'OPTIONS') {
   return 204;
  }
 }
 # 静态资源放行
 location ~ \.(gif|jpg|jpeg|css|js|svg)$ {
  proxy_pass http://mir;
  proxy_set_header Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Fonwarded-For $proxy_add_x_forwarded_for;
  expires 30d;
 }
 # 添加跨域请求头
 add_header 'Access-Control-Allow-Origin' '*';
 add_header 'Access-Control-Allow_Credentials' 'true';
 add_header 'Access-Control-Allow-Headers' 'Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
 add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH';
 #error_page  404              /404.html;

 # redirect server error pages to the static page /50x.html
 # 配置常规的友好错误提示页
 error_page   500 502 503 504  /50x.html;
 location = /50x.html {
  root   html;
 }

}

nginx 里的 url 匹配，有一个特点，就是最先匹配原则，每一个请求，从上往下，先匹配到哪一个规则，就直接跳转这个规则对应配置的 url

题外话

因为第三方的系统，其实算是一个常规的系统，比如，标配有登陆页，我们需要吞掉登陆的这个步骤，所以，我们需要在动手脚的 x.min.js 里检测第三方系统正确加载后，是否需要进行登陆操作，同时为了友好起见，我们需要添加一个遮罩层，在我们对第三方的页面处理干净之前，得先遮住不让客户看到。
等正确载入第三方的系统后，就可以按需要进行功能裁剪，样式替换