Illustration | A cross-domain problem confused me

[[439558]]

This article is reprinted from the WeChat public account "Amateur Coder", author Amazing10. Please contact the Amateur Coder public account to reprint this article.

Hello everyone, I am an amateur coder. I encountered a problem when I was working on a full-stack project recently.

Since it is a project with separated front-end and back-end, the front-end and back-end will actually run on different domain names. If it is developed locally, the front-end and back-end will also be deployed on different ports.

At this time, if the front-end directly requests the back-end interface, it will encounter the so-called cross-domain problem.

Cross-domain error

Same-origin policy

When it comes to cross-domain, we first need to explain why such cross-domain problems occur. This is actually due to the browser's same-origin policy.

The same-origin policy is an important security policy in browsers, which was introduced by Netscape in 1995. The purpose of the same-origin policy is to limit the interaction between different sources, thereby effectively avoiding browser-level attacks such as XSS and CSFR.

Homologous means that the protocol, domain name (host) and port (port) of the two request interface URLs are consistent.

Same-origin policy

For example, the following example:

Homologous and non-homologous interfaces

When it comes to browser attacks, XSS refers to malicious attackers inserting malicious HTML code into web pages, taking advantage of users' trust in designated websites.

CSFR refers to cross-site request forgery, which is a technique used by attackers to trick users' browsers into visiting a website that they have authenticated and performing some operations (such as sending emails, messages, or even financial operations such as transferring money and purchasing goods).

Since the browser has been authenticated, the visited website will think it is a real user operation and execute it. This takes advantage of a loophole in user authentication on the Web: simple authentication can only ensure that the request is sent from a user's browser, but cannot ensure that the request itself is voluntarily sent by the user. This actually takes advantage of the website's trust in the user's web browser.

Therefore, based on the browser's homology judgment, some behaviors of the website can be selectively restricted. For example, non-homologous sites will be restricted from accessing cookies, localStorage, and IndexDB, and will not be able to obtain the web page DOM and JavaScript objects, and even AJAX requests will be blocked.

In this way, the purpose of attacking by using browsers and historically visited sites can be effectively limited.

Cross-domain issues

In essence, it seems to be a good thing that browsers do not allow cross-domain requests, because it is safer for the front end. Why does the same-origin policy, which was designed with great effort, become a problem for us?

In fact, this is unavoidable. After all, for projects with separated front-end and back-end, cross-domain requests are necessary. For example, in a local development environment, the port numbers may be different.

Cross-domain issues in local environment

The same situation occurs in an online environment.

Cross-domain issues in online environments

Solution

1 JSONP cross-domain

The cross-domain issues mentioned above are actually due to the use of AJAX/XMLHttpRequest/Fetch API to initiate requests, but in fact, calling JS files on a web page is not affected by cross-domain. Not only that, tags with src attributes have cross-domain capabilities.

JSONP is a cross-domain solution that takes advantage of the above features. The principle of JSONP is to send a GET request with a Callback parameter, and the server will piece together the interface return data into the Callback function and return it to the browser. The browser will parse and execute it, so that the front end can get the data returned by the Callback function.

JSONP cross-domain

The front-end code only needs to insert the <script> tag into the page, define the callback function, and request the back-end interface through src:

 <script>
    var script = document.createElement( 'script' );
    script.type = 'text/javascript' ;
    script.src = 'http://www.b.domain.com:8080/main?callback=handleCallback' ;
    document.head.appendChild(script); 
  
 // callback function
 function handleCallback(res) {
        alert(JSON.stringify(res));
 }
 </script>

The backend needs to wrap the JSON data with the callback parameter sent by the client as the function name in the corresponding interface and return the data to the client.

 handleCallback({ "error" : 0, "status" : "0"})

JSONP seems very convenient, but it actually has a lot of limitations. Because tags with src attributes such as script and img use GET requests when introducing external resources, JSONP can only use GET to send requests, which is why this method has gradually been eliminated.

2 Proxy cross-domain

Since the cross-domain problem is a protection measure of the browser itself, it is actually possible to make cross-domain requests in disguise by adding a proxy layer between the front and back ends.

Proxy cross-domain

Webpack Server Proxy

In webpack, you can quickly obtain the ability of interface proxy by configuring proxy. At the same time, the URL requested by the front-end does not need to have a domain name, and the proxy server will automatically map the request to a same-domain request.

You can configure the proxy in the front-end webpack.config.js:

 module.exports = {
 ...
 output : {...},
 devServer: {
 port: 3000,
 proxy: {
 "/api" : {
        target: "http://localhost:3001"  
 }
 }
 },
 plugins: []
 };

Nginx reverse proxy

The implementation idea is actually the same as the webpack proxy, except that Nginx is used as a springboard.

Nginx reverse proxy

Take Nginx configuration as an example, which is to proxy local port 3000 to 3001, so that cross-domain debugging can be performed locally.

 server {
 listen 3000;
 server_name localhost; 
 
 location /api {
 proxy_pass http://localhost:3001; #Reverse proxy
 }
 }

The principles are similar, except that the proxy operation is set on the backend. If it is a node project, you can directly use the http-proxy-middleware plug-in for proxy. In essence, webpack also uses this package for proxy service, but now it is placed on the server.

Node middleware proxy

An example of node+express+http-proxy-middleware:

 var express = require( 'express' );
 var proxy = require( 'http-proxy-middleware' );
 var app = express(); 
 
 app.use( '/' , proxy({
 //Proxy cross-domain target interface
    target: 'http://localhost:3001' ,
 changeOrigin: true , 
 
 // Modify the response header information to achieve cross-domain and allow cookies
    onProxyRes: function (proxyRes, req, res) {
        res.header( 'Access-Control-Allow-Origin' , 'localhost' );
        res.header( 'Access-Control-Allow-Credentials' , 'true' );
 },
 })); 
 
 app.listen(3000);

3 CORS cross-domain

CORS (Cross-Origin Resource Sharing) refers to cross-origin resource sharing. It is a browser-side mechanism that allows the server to mark domains other than its own, so that the browser can access and load resources across domains.

Generally, modern browsers support CORS cross-domain, only old browsers, such as IE10 and below, do not support it.

This means that although the browser will actually adopt the same-origin policy to restrict cross-domain access, it also provides the server with an option to optionally provide cross-domain capabilities through CORS.

CORS cross-domain

For example, in the example above, the left side represents the front-end web page, and the right side represents the server. The front-end is deployed under the domain name domain-a, but there are two resources that need to request resources from different domain names.

When the resource source is inconsistent with the domain where the front-end itself is located, a cross-domain request will occur. At this time, CORS can be used to control whether cross-domain resource requests are allowed.

CORS is a capability provided by the browser, and the control and communication to implement CORS is done on the server side. That is, as long as the server allows CORS for the corresponding domain, cross-domain communication can be performed.

Simple request

The browser divides CORS requests into two categories based on the request method and HTTP header information: simple requests and non-simple requests.

A request is considered a simple request if the following conditions are met:

• The request method is one of GET, POST, or HEAD.
• The HTTP header only contains Accept, Accept-Language, Content-Language, and Content-Type.

The value of Content-Type is limited to text/plain multipart/form-data application/x-www-form-urlencoded

Simple request

• Any XMLHttpRequestUpload objects in the request do not have any event listeners registered; XMLHttpRequestUpload objects can be accessed using the XMLHttpRequest.upload property.
• No ReadableStream object is used in the request.

The flow for a simple request is simple:

Simple request process

• When the browser makes a CORS request, it adds the Origin field (the last line) to the header to indicate the request domain:

 GET /resources/ public -data/ HTTP/1.1
 Host: bar.other
 User -Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-us,en;q=0.5
 Accept-Encoding: gzip,deflate
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Connection : keep-alive
 Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
 Origin: http://foo.exampl

The server receives Origin and decides whether to approve the cross-domain request:

• If the request is approved, the server will add CORS-related headers to the returned response. For example, Access-Control-Allow-Origin is a required field, indicating the domain name that can accept the request, and * indicates any domain name.
• If the request is not approved, the server will return a normal HTTP response. Since it does not contain Access-Control-Allow-Origin, it will be discovered by the browser, thus throwing the error at the top of this article.

 HTTP/1.1 200 OK
 Date : Mon, 01 Dec 2008 00:23:53 GMT
 Server: Apache/2.0.61
 Access-Control-Allow-Origin: *
 Keep-Alive: timeout=2, max =100
 Connection : Keep-Alive
 Transfer-Encoding: chunked
 Content-Type: application/xml

Not a simple request

Any request that does not satisfy a simple request is a non-simple request.

The characteristic of non-simple request is that before sending the formal request, a pre-check request will be initiated. The formal request will be sent only when the server agrees to the pre-check request.

For example, here is an example. Suppose you need to send a request that contains a custom header field X-PINGOTHER and the Content-Type is application/xml.

It can be seen that this request is definitely not a simple request, so it needs to go through the pre-check process.

• The pre-check request uses the OPTIONS request method. The Origin will be indicated in the request header, and two special header fields are also required.
  • Access-Control-Request-Method: used to indicate which HTTP request methods will be used in formal requests, such as POST in the example;
  • Access-Control-Request-Headers: Used to indicate which additional header fields will be sent in the formal request, such as X-PINGOTHER and Content-Type in the example.
• After receiving the pre-check request, the server will check the above fields to determine whether the cross-domain request can be accepted. If it can, the Access-Control-Request-Method and Access-Control-Request-Headers fields will be added to the response header to indicate the acceptable request method and request header.
• After the browser receives the successful pre-check response, it will start to initiate the formal request. The formal request process is basically the same as the simple request. That is, the Origin field is added to the request header, and the server's response also returns the corresponding CORS required fields.

Non-simple request process

Although the CORS cross-domain solution is a mechanism supported by browsers, the implementation is indeed on the server side. However, the workload is not large. You only need to set the domain name, HTTP header, request method and other parameters that allow cross-domain requests.

For example, in a node+express project, you only need to add the following code to achieve the purpose of cross-domain for any domain name.

 app. all ( '*' , function (req: express.Request, res: express.Response, next : express.NextFunction) {
 //Set the domain name allowed to cross domain, * means any domain name is allowed to cross domain
  res.header( "Access-Control-Allow-Origin" , "*" );
 //Allowed header types
  res.header( "Access-Control-Allow-Headers" , "*" );
 //Cross-domain request method allowed
  res.header( "Access-Control-Allow-Methods" , "DELETE,PUT,POST,GET,OPTIONS" );
  if (req.method.toLowerCase() === 'options' )
 res.sendStatus(200) //Let options try to request a quick end
 else  
 next ()
 })

Summarize

Cross-domain issues are very common in Web development, and they are not complicated to solve. In addition to the above solutions, there are also solutions such as Iframe, postMessage, and websocket.

But in general, it is not as commonly used as the above three. A more serious front-end and back-end separation project still uses the CORS solution for cross-domain. It saves time, effort and worry.