This article has participated in the Denver Nuggets Creators Camp 3 “More Productive writing” track, see details: Digg project | creators Camp 3 ongoing, “write” personal impact.

What is cross-domain?

Our browser, for security reasons, only allows Ajax access to interfaces in this domain. You cannot cross domains without authorization.

This statement is also called the same origin policy.

So, what is a local domain?

  • Same protocol: for example, both HTTP and HTTPS
  • Same domains: such as github.com/pany-ang and github.com/v3-projects…
  • The same port: for example, if the port number is not specified in the domain name, the default HTTP port is 80, and the default HTTPS port is 443.

Doing all three at the same time is the local domain.

Here’s an example:

Github.com/pany-ang and github.com/v3-projects…

The above two domains do not exist cross-domain, they are HTTPS protocol, domain name github.com, port 443.

That is, when our page makes Ajax requests, if the server interface is not the local domain interface, then it is cross-domain (that is, the domain name of the current page and the domain name of the interface are not “local domain”).

How to solve cross-domain problems?

Since browsers don’t allow us to cross domains, but we want to implement a cross-domain invocation interface, we need to find a way to allow our application to cross domains.

JSONP

This is a very old-fashioned method, and it’s not used much anymore.

Before we talk about this implementation, we need to understand one thing:

<script src="Here is the path to the JS file."></script>
Copy the code

The above code is simply to introduce an external JS, presumably we all understand. The net effect is equivalent to:

<script>Here is the source code in the introduced JS file</script>
Copy the code

But the code could also be written like this:

<script src="Here is the path to the interface provided by the back end."></script>
Copy the code

The net effect is equivalent to:

<script>Here is the data returned by the back-end interface</script>
Copy the code

It is true that when we access an interface through Ajax, it will not be considered cross-domain by the above code.

This way, we can get the data returned by the interface without worrying about cross-domains.

But here’s the thing,

The data we get is usually in JSON format, and the data is just data, it’s “dead”. We usually get the data through AJAX and then use a callback function to process it, but now we get the data in this “clever” way and there seems to be no way to process it.

In this case, we will do this: when the back end returns data, add a function name: “data” becomes “function name (data)”, and put the original data in the position of the parameter.

Changing “data” to “function name (data)” results in:

<script>Here is the data returned by the back-end interface</script>
Copy the code

To:

<script>Function name (data)</script>
Copy the code

If the returned data is preceded by a function name, and our front-end code has a prewritten function with the same name, it is equivalent to calling the function in our front-end code. We can use this function to process the returned data.

CORS

Here I will briefly introduce the CORS approach to cross-domain implementation (which is actually quite simple…).

Principle: When sending Ajax requests, if they cross domains, the browser will automatically help us add a request header Origin to the request, and the background will determine whether the data should be returned. If the background determines that “data should be returned”, Add a response header access-Control-allow-origin to the return result; The browser then determines whether Origin is present in the response header. If so, we can successfully retrieve the data across domains. If not, we fail to cross domains.

With this method, there is little change in the front end and a similar statement needs to be added to the back end:

res.header("Access-Control-Allow-Origin", "*"); // * Allows access by all domain namesCopy the code

The reverse proxy

How it works: Since cross-domain problems are caused by the same origin policy of the browser, instead of calling the back-end interface directly through the browser, we enable an intermediate proxy service that requests the corresponding interface.

Using Vue as an example, the configuration of the development environment is as follows:

proxy: {
  '/api/': {
    target: 'http://xxxxxx/api/'.ws: true.pathRewrite: {
      '^/api/': ' '
    },
    changeOrigin: true.secure: false}}Copy the code

For production environments, nginx can be used as a reverse proxy.

other

Of course, there are other cross-domain scenarios, such as domain lowering and postMessage, but these are commonly used to solve purely front-end cross-domain problems (such as A accessing B page’s data), and this article won’t explain them too much.