preface

As for this matter of cross-domain, since I met, understand, this matter has passed. I always thought it was a small problem, and I think you all understand. Until I want to teach my sister when the front end encountered this problem, it was found that the whole logic of the problem is actually quite around. Knowing how to solve a problem is easy, but explaining why it happened is more complicated. So suddenly I’m curious, you all understand the logic. So I asked a question in a couple of communication groups

Why do many people have situations where local environments cross domains and online environments don’t

The answers are not quite correct, but one of the students before and after the answer is very accurate. At this point I sort of realized that it was my backend experience that had helped me understand cross-domain so well that I didn’t have a special feeling. So LET me start with that question and talk about cross-domain.

How does the front-end code work

Let me start with two seemingly unrelated questions.

Where does our front-end code run?

The server or something? It runs directly on the system. The answer is that it runs in the browser on the user’s computer. The backend may want to laugh at this question, you don’t say, I also went to the group to ask, there are really a lot of front-end think the code is running on the server. Let’s move on to the second question.

How does the user’s browser get our code?

From our servers? How to take? The path is like this: the server is accessed through a domain name request, and the server’s Nginx software (for example, nginx, or others) responds to the request and returns the corresponding front-end code file.

What is cross-domain

Ok, let’s get to the point, let’s first throw out the definition of cross-domain what is cross-domain

Too many concepts I will not repeat and repeat here, let me say my understanding:

As mentioned above, our code runs in a browser, so the browser’s restrictions on different sources are actually restrictions on our code. The limit is whether the requested address port is the same as the address port of the current page.

What is the address port of the current page? Look at the second question we had earlier. So it is actually the browser gets the address of the code and the code run time request address is inconsistent caused by cross-domain. Is the logic any clearer? Let’s go back to the preamble.

The online environment

What is an online environment like in general? Most of the front ends probably don’t need to be in the pipeline, but it’s good to know. In general, the online server runs an NGINx software, and nginx processes the request. If it is to obtain front-end code, it directly returns the code file. If it is to request the back-end service, it will forward to the back-end program, wait for the program to process the result, and then Nginx returns the result to the user.

So how do you tell the difference between getting a front-end code request and a back-end service request? By domain name? Api.xxx.com | admin.xxx.com? This is not good, the cross domain. General situation is the same domain name, according to the path prefixes, xxx.com/api/xxx | xxx.com/admin/xxx. In fact, there is a conflict between the front end path and the back end service path, but most developers don’t use apis as a prefix, so this is rarely a problem.

Distinguish by path prefix, then there is no cross-domain problem.

The local environment

You know, the local people are basically running projects on the CLI with commands like run and start. Let’s look at the description of vue-CLI

The vue-cli-service serve command starts a development server (based on webpack-dev-server) and comes with hot-modole-replacement modules out of the box.

What is a development server? A virtual machine? No, when I say server, I actually mean server software, which is web service software, which is similar to nginx. For the sake of confusion, I’m going to use nginx to refer to server software. Server also refers to the server machine.

The purpose of the locally running nginx(development server) is to listen for requests at localhost:8080 and return the code you wrote. Also comes with a module thermal overload mentioned here, because we write the vue code browser cannot be identified, actually cannot return directly, when launched officially packaging is translated into the native js code, the thermal overload is also a similar steps, but it can be quickly local package, you can just modify the code can see the effect in the browser.

Back-end services are usually either running on a colleague’s machine or running a back-end project on your own computer. In the latter case, if the backend runs a nodejs project, it also runs a cli command, which also starts an nginx that listens for requests at localhost:3000. Note that nginx started in the back end and nginx started in the front end are not the same and run separately.

Regression problems

We said that online environments are generally not cross-domain, so let’s think, can we make the local environment mimic the online approach to solve cross-domain problems?

  • First, use the same domain name and port. Like the local environment mentioned above, how about we both listen on localhost:8080? Is it ok for both nGINX to listen on the same port address? No, the ports will conflict.
  • Can you combine two Nginx’s into one? No, because the CLI code is hard to change, and people who can change the CLI code probably don’t need to ask cross-domain questions.
  • What if I can run nginx locally instead of using the CLI? No, because the CLI runs nginx with hot reloading and it’s necessary, otherwise every time you change your code you have to package it to see the effect in the browser, which is unacceptable.
  • What if I can run real nginx locally and also run nginx on the CLI? This method does work, but this is not the case online, this is the logic of the proxy. To do this, run a real Nginx, configure another public domain address, such as localhost:8888, and forward/API requests to localhost:3000 and /admin requests to localhost:8080. All three nginx will run simultaneously. This method is mainly troublesome, the agent can look at the following method.

Similarly, if the back-end service is running on a colleague’s machine, it is even more difficult to do, because even the domain name cannot be the same.

Now I think you get a sense of why this is happening.

The agent

How do our common agents solve this problem? This is usually configured in the vUE configuration file

devServer: {
    proxy: {
      '/api': {
        target: 'localhost:3000/'.changeOrigin: true}}},Copy the code

This configuration tells nginx of the front-end project to forward all requests to the API prefix path to localhost:3000. Change the address of the back end of the request to localhost:8080, and then the front-end Nginx takes over all the requests, similar to the online Nginx, with the path prefix to distinguish the requests, and then separately processing. It’s a little different than online, but it’s basically the same principle, and it’s a perfect solution.

Other options

The most typical is the CORS scheme.

In general, there are two directions to solve the cross-domain problem, one is to bypass the cross-domain restriction, the other is to remove the cross-domain restriction. Agents belong to the former and CORS belong to the latter. Nginx forwarding is equivalent to the postman-like principle of the request, is not restricted by cross-domain, because cross-domain is restricted by the browser. Therefore, forwarding by Nginx is equivalent to circumventing the restriction. Cors, on the other hand, allows the browser to be unrestricted through certain configurations and requires the cooperation of the back end.

If you do not need to cross domains in your online environment, you are not recommended to use CORS, because Chrome added cross-domain restrictions in 19 years, it is becoming more and more troublesome to remove restrictions, see this link for more details

conclusion

In summary, the online environment does not cross domains because the same NGINx handles the same request address, while the local environment cannot do so because the CLI cannot be changed and can only be configured to achieve similar effects.

In this paper, SSR will not be discussed. The browser limits the js code running in the current ADDRESS of the HTML page to access other domain names because the JS code can be obtained from different places. In ancient times, many people get jQ by CDN address (acceleration server). Is that cross-domain? No. Take a closer look at the same origin policy.