What the hell is cross-domain? Do you understand?

[[433686]]

Cross-domain is a common topic. Recently, I encounter it when debugging with the backend or working on micro frontends. It’s a good opportunity to write an article to summarize it.

What is cross-domain

"Cross-domain" here refers to resource access between different sources. As long as the requested URL has the following differences, it is considered "cross-domain":

• Protocol: http, https, ...
• domain name
• port

Some people may think that my own website must only access my own server and must be deployed on a domain name.

But sometimes, a web page may need to connect to multiple backend services: one for payment, the other for user information. Each group's backend may have its own domain name. In such a scenario, cross-domain is very common.

Why is there cross-domain

The "cross-domain" problem we often talk about is actually the restriction of "cross-domain" access. I believe everyone is accustomed to the following error:

This "cross-domain" restriction is actually a built-in security mechanism of the browser. Only when a cross-domain request operation occurs on the browser will the browser automatically throw the above error.

Note that this limitation only occurs on browsers. If you use tools such as Postman to access URLs, there is no "cross-domain" limitation. After all, Postman doesn't even have domain names, so how can there be "cross-domain" limitations?

CORS

Although browsers have restricted "cross-origin" access for security reasons, the need to access resources from different sources is inevitable during development, so W3C has developed the CORS (Cross-origin resource sharing) mechanism.

Many people have always thought that CORS = cross-domain. In fact, CORS is a solution to "cross-domain".

It should be noted that CORS is a "new" protocol (at least it is new to IE7 before), which requires not only browser support but also the support of the backend server.

There is nothing much to say about browser support, it is just a question of whether the browser version supports it:

Then the backend server needs to support it. The server needs to add the Access-Control-xxx-yyy field to the Response Header. The browser can only release the request after it recognizes it. For example, the most common way is to add the Access-Control-Allow-Origin return header, and set the value to the domain name that needs to be released.

Simple Requests vs. Non-Simple Requests

Browsers classify CORS requests into simple requests and non-simple requests.

When a simple request is sent, the Origin field will be automatically added to the HTTP request header to indicate the current source (protocol + domain name + port), and the server will decide whether to release it.

For non-simple requests, an OPTIONS pre-check request will be sent to the server first, and then a normal CORS request will be sent if it passes.

For simple requests, the request method is one of the following three:

• Head
• Post
• Get

And the HTTP request header fields cannot exceed the following fields:

• Accept
• Accept-Language
• Content-Language
• Last-Event-ID
• Content-Type

At the same time, Content-Type can only have three values:

• application/x-www-form-urlencoded corresponds to normal form
• multipart/form-data for file upload
• text/plain corresponds to text sending (generally not used)

Any request that does not meet the above conditions is considered a non-simple request.

Many people may naturally think that POST requests are non-simple requests, because we often see that OPTIONS is sent first when sending POST. In fact, it is because we usually send data in JSON format, and the Content-Type is application/json, so such POST requests are non-simple requests.

Access-Control-xxx-yyyy

When the CORS request is a simple request, the request will detect the following fields in the returned header:

• Access-Control-Allow-Origin: Specifies which sources can share resources (including protocol, domain name, and port).
• Access-Control-Allow-Credentials: When a request needs to carry cookies, this field needs to be set to true to allow cookies to be carried.
• Access-Control-Expose-Headers: Since the XMLHttpRequest object can only get the six basic fields of Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, and Pragma, if you want to get other fields, you need to specify them here.

When the CORS request is not a simple request, the browser will first send an OPTIONS preflight request, which will check the following fields:

• Access-Control-Request-Method: specifies the accessible methods. For non-simple requests, RESTful methods such as PUT, PATCH, and DELETE may be used. The server needs to add these method names as well.
• Access-Control-Request-Headers: Specifies the additional information that will be added to the HTTP request header. A common scenario is that the backend sometimes puts some environment parameters in the request header. If this field is not used to specify the released fields, then "cross-domain" restrictions will appear.

If the OPTIONS request does not pass the server's verification, a normal HTTP request will be returned without the CORS return information, so the browser will identify it as "cross-domain".

To sum it up, when the Console reports an error, you just need to add the corresponding field to the header returned by the server.

CORS Middleware

Whether for Express or KOA, we no longer need to manually add the above fields. We can easily add the above fields by adding a cors middleware, which is more elegant to write:

 var cors = require( 'cors' ); 
 
 var corsOptions = {
  origin: function (origin, callback) {
    // db.loadOrigins is an example call to   load  
    // a list of origins from a backing database  
    db.loadOrigins( function (error, origins) {
      callback(error, origins)
 })
 }
 } 
 
 app.use( '/' , cors(corsOptions), indexRouter);

JSONP

What about the case where the browser does not support CORS? Although it is unlikely at present, how did people solve the cross-domain problem in the era when CORS did not exist? The answer is JSONP.

Its principle is also very simple: although the browser restricts HTTP cross-domain, it does not restrict cross-domain requests for obtaining script tag content.

When we insert a <script src="xxx.com"> tag, a GET request will be sent to obtain xxx.com, and this GET request does not have the "cross-domain" restriction. This method can solve the cross-domain problem.

Server implementation:

 router.get( '/' , (req, res) => {
  const { callback_name } = req.query;
 res.send(`${callback_name}( 'hello' )`) // Return to JS code, call callback_name function, and pass in hello
 });

Front-end implementation:

 function jsonpCallback(params) {
 alert( 'Execute the jsonpCallback function defined in public/index.html and pass in' + params + 'parameters' );
 } 
 
 
 const jsonp = async () => {
 // Create a script tag
  const script = document.createElement( 'script' );
  script.type = 'text/javascript' ;
  script.src = 'http://localhost:9000/user?callback_name=jsonpCallback'  
 // Add tags
  document.body.appendChild(script);
 // Get the data and remove it
  document.body.removeChild(script);
 } 
 
 jsonp();

When the jsonp function is called, a script tag is automatically created, and the request is placed in the scr, which automatically initiates a GET request. The server will directly return a string of JavaScript code, and then the front-end executes this JS code obtained from the server to obtain the back-end data.

Cross-domain scenarios

"Cross-domain" not only exists in interface access, but also in the following scenarios:

• The most common scenario for the front-end to access a cross-domain URL is to add a cors return field to the back-end.
• Micro frontend: Resource access between the main application and the sub-application may involve "cross-domain" operations, requiring the sub-application/main application to add cors
• Login redirection: It is essentially the same as the first one, but the phenomenon is different. For example, when you visit abc.com, some websites will redirect to their own login page passport.abc.com. If passport.abc.com does not set CORS, cross-domain will also occur.

Summarize

In general, what we often call "cross-domain" is actually the restrictions imposed by the browser itself when obtaining resources from different sources (protocol + domain name + port).

In the past, developers would use JSONP to solve the cross-domain problem by generating a script tag and automatically initiating a GET request. However, this method is very unsafe and is not recommended.

Nowadays, browsers have fully supported the CORS mechanism. You only need to add the corresponding return header Access-Control-xxx-yyy on the server. When the browser reports a "cross-domain" error, you can add the missing field on the server.

When developing on the Node side, we can directly use the cors middleware to configure it, without having to handwrite the fields in the return header.