Webpack's proxyTable settings cross-domain

Why use proxyTable

Very simple, two words, cross-domain.
In the normal project development environment, cross-domain problems are often encountered, especially when developing with a scaffolding tool such as vue-cli, since the project itself needs to occupy a port to start the local service, cross-domain problems will inevitably occur. question. Of course, there are many solutions for cross-domain, and I will not list them one by one. Next time, I will talk about it separately. It is a more convenient choice to use proxyTable proxy to achieve cross-domain in projects that use webpack as a build tool.

How to use proxyTable

Take the vue-cli used before as an example. We first need to find the index.js file in the config folder in the root directory in the project directory. Since we are using it in the development environment, it is natural to configure it in dev:

dev: {
  env: require('./dev.env'),
  port: 8080,
  autoOpenBrowser: true,
  assetsSubDirectory: 'static',
  assetsPublicPath: '/',
  proxyTable: {
    '/api': {
      target: 'http://www.abc.com',  //目标接口域名
      changeOrigin: true,  //是否跨域
      pathRewrite: {
        '^/api': '/api'   //重写接口
      }
    },
  cssSourceMap: false
}

The effect of the above code is to proxy a request from the local port 8080 to the domain name http://www.abc.com:

'http://localhost:8080/api' ===> 'http://www.abc.com/api'

No use under unified project name

In the above case, there is a unified project name api, so it is a good match, which is equivalent to directly replacing the interface name starting with api with the target domain name for access, but if the background returns There is no unified project name for our front-end interface? Before, I did the conversion one by one. It doesn't matter if there are fewer interfaces, but it is definitely unrealistic. Some time ago, I was inspired by the interviewer in an interview and came up with such a tricky solution:
``
//Add a custom project name before the interface address
let someApi = 'api' + '/xx/xx';

dev: {
env: require('./dev.env'),
port: 8080,
autoOpenBrowser: true,
assetsSubDirectory: 'static',
assetsPublicPath: '/',
proxyTable: {
'/api': {
target: ' http: //www.abc.com ', //target interface domain name
changeOrigin: true, //whether cross domain
pathRewrite: {
'^/api': '/' //rewrite interface
}
},
cssSourceMap: false
}`
``
The project name api here is artificially added by us, and it disappears after passing through the proxy, so we only need to configure one copy when configuring the proxy, but pay attention to distinguish the development environment and the online environment when writing the interface address That's it.

The principle of proxyTable

I checked online and found that this proxy is actually done using the http-proxy-middleware plug-in. As for the operating mechanism of this plug-in, because it is in English and has limited capabilities, I will not delve into it. But what I want to explore is how this proxy method is actually done. I saw someone on the Internet saying that our local server actually forwards the request to the target server. The reason why cross-domain occurs is because the browser has the restriction of the same-origin policy, but the server does not, so the mechanism that this proxy method can achieve is roughly:

Local server -- "Proxy -- "Target server --" After getting the data, disguise the return value of the local service request through the proxy -- "Then the browser successfully receives the data we want.

This is my simple understanding. According to this understanding, as long as the server allows cross-domain, can anyone get its data? Wouldn't the homology strategy be greatly weakened? I still don't understand this problem too much, I hope that friends who have ideas will leave a message and correct me!