Nginx solves cross-domain issues and embeds third-party pages

Preface

Our own system needs to load some components from the third-party system. The plan is for a third party to develop and provide relevant interfaces. We obtain data through the interfaces, and then use these data to implement relevant functions in our system.

Unfortunately, the leadership did not coordinate. If the regular way doesn't work, then you need to do something fancy.

As mentioned before, we use the interface to pull data and re-render. This is a relatively common way of playing. The disadvantage is that we need to re-implement related modules and require the other party to open the interface.

Now we can only use abnormal channels. For example, it is easy to think of that we directly embed the page into our own system, and at the same time we need to control the style and components of the third-party page.

difficulty

The method mentioned above is to plan an iframe in our own system and introduce a third-party system through the src attribute.
The biggest problem here is cross-domain. The most likely solution mentioned on the Internet is to use postMessage to cross domain. Unfortunately, this still requires cooperation from a third party.

Cross-domain definition

First of all, in a narrow sense, homology means that the domain name, protocol, and port are the same.
Cross-domain means that the browser cannot execute scripts from other websites. It is caused by the browser's same-origin policy, which is a security restriction that browsers implement on JavaScript.

Features of nginx

Reverse Proxy

Configure a URL. If a user visits this URL, the proxy will be directed to the URL they actually need.

Separation of static and dynamic

As the name implies, dynamic resources (which require server calculations) are separated from static resources (generally referring to resources related to static pages such as html, css, js, img, etc.)

Try to achieve

Because our A application uses port 80, and the third-party B system also uses port 80, we need to add a suffix to distinguish the proxy to the B system. The approximate URL is as follows

# A's url
http://localhost/
# B suffixed url
http://localhost/three-part
# B's actual url
http://172.16.1.1/

Normally, when we visit localhost, we will be taken to the homepage of system A. When we visit 172.16.1.1, we will be taken to the homepage of system B. If we visit through the proxy URL, nginx will actually proxy it to 172.16.1.1/three-part. Yes, when testing, did you find that the suffix was carried over? ? It is possible that I am not professional and have not configured it properly, but this is the result of my test.

The idea of ​​the above configuration is to let the two applications have the same IP and port, and then the iframe in application A loads the homepage of application B, then it can be operated through js

Unfortunately, the only way is to configure a different port, for example, configure the proxy URL of application B to localhost:81/. In this way, you cannot write js to modify application B in the page corresponding to the iframe of application A.

Final result

As I f12 on application B, I found that they encapsulated a x.min.js file, which will be loaded when logging in and entering the homepage.
So, here comes the trick. I directly rewrite their js file, put the logic I need at the end of the file, and then let the page load the modified js file on my server when loading this x.min.js, instead of loading the x.min.js in the third-party server.

The schematic diagram of the whole process is shown below:

Below is the nginx configuration I have configured and am using

upstream mir{
    server 10.1.128.58:80;
}
server {
 listen localhost:8001; # nginx needs to listen to the URL and the corresponding port location =/static/mir.min.js {
  root C:/r9/bin/resources;
 }
 location / {
  # It can be understood that a url variable name is used here, and this variable name is defined in upstream proxy_pass http://mir;
  # The following items are considered standard cross-domain configurations, just copy them 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;
  }
 }
 # static resource release 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 cross-domain request header 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
 # Configure a regular friendly error page error_page 500 502 503 504 /50x.html;
 location = /50x.html {
  root html;
 }

}

The URL matching in nginx has a feature, which is the first matching principle. For each request, from top to bottom, whichever rule is matched first, it will directly jump to the URL configured for this rule.

Off topic

Because the third-party system is actually a regular system. For example, it comes with a login page as standard. We need to handle the login step. Therefore, we need to detect in the x.min.js that the third-party system is correctly loaded and whether a login operation is required. At the same time, for the sake of friendliness, we need to add a mask layer. Before we clean up the third-party page, we have to cover it up so that customers cannot see it.
After the third-party system is correctly loaded, you can tailor functions and replace styles as needed.

This is the end of this article about how nginx solves cross-domain problems and embeds third-party pages. For more information about nginx cross-domain embedding of third-party pages, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!