nginx 解决跨域问题嵌入第三方页面-662P.COM

本文主要介绍了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 里检测第三方系统正确加载后，是否需要进行登陆操作，同时为了友好起见，我们需要添加一个遮罩层，在我们对第三方的页面处理干净之前，得先遮住不让客户看到。
等正确载入第三方的系统后，就可以按需要进行功能裁剪，样式替换

nginx

前言

困难