Angular uses CORS to implement cross-origin Solutions

Angular uses CORS to implement cross-origin Solutions

In the past, there was a very old article on the Internet, including the keyword "cross-origin summary and solution for Baidu" now, the first few recommendations were "Javascript cross-origin summary and solution ". after reading it, I felt that the method was a little outdated. Some of them were documents. domain and iframe solutions are somewhat "ugly" and do not feel suitable for some projects.

Taking iframe as a front-end engineer, I hate iframe, which not only increases the performance load, but also is difficult to control.

It is relatively simple to implement cross-origin in Angular applications, basically in two ways. one is JSONP, and the other is through CORS. the former is a relatively old method, and I feel a little more powerful, so this article mainly describes how Angular works with CORS.

Try not to use JSONP if possible. This is a principle that begins with Angular cross-origin. In any case, the label embedding feeling of the script is still low.‍‍

Angular advocates frontend and backend separation, so which side implements cross-origin is a problem. this has to be said the limitations of the front-end technology. Even a relatively useful JSONP is powerless for non-GET requests, because it basically uses scripts to get some resources.

JSONP can only GET restrictions. In the API scenario where Angular advocates RESTful APIs, it completely restricts the use of JSONP and PUT APIs. in addition, JSONP's error handling is weak and unsatisfactory. in short, front-end cross-domain implementation has various limitations, such as document. domain can only be used when the primary domain is the same and the subdomain is different.

To sum up, although the front-end can handle cross-origin requests in multiple ways, there are many but not precise, and the disadvantages are obvious. A better way is to participate in processing through the backend. This method is not only more adaptable, but also requires the front end to send normal Ajax requests. this technology is called CORS.

Cross-Origin Resource Sharing is the most recommended Cross-Origin processing solution. not only applicable to various methods, but also more convenient and simple. of course, only modern browsers support such hanging things, and IE8's old antiques will be skipped.

CORS implementation principle

Although cross-origin through CORS is basically implemented by the backend, it is a powerful front-end. you still need to master this principle so that when you encounter unreliable backend, it will not... you know

The essence of CORS allows the server to share resources by adding a response header Access-Control-Allow-Origin and allowing each requested service to directly return resources. it uses HTTP interaction to determine whether the request source is eligible to request the resource, and sets the HTTP Header to control the resource access permissions.

The specific process is as follows:

 
 

  
  
$ Http. get ('www .cros.com/api/data', parameter params :{
  
  
Name: 'stubborn Shi'
  
  
}})
 
 

Set the response header at the backend:

 
 

  
  
Access-Control-Allow-Origin: "*" 
  
  
Access-Control-Allow-Methods: "GET" 
  
  
Access-Control-Max-Age: "60"   
 
 

Then you can observe the browser's behavior and find it interesting. Without your intervention, the browser finds that this is a cross-origin request. therefore, instead of sending a GET request directly, it sends an OPTIONS request asking if the resource can be accessed across domains. This process can be called "pre-check ".

Then we can see that the response of OPTIONS returns information similar to the following:

 
 

  
  
HTTP/1.1 200 OK  
  
  
 
  
  
 
  
  
Date: Mon, 01 Dec 2013 01:15:39 GMT  
  
  
Server: Apache/2.0.61 (Unix)  
  
  
Access-Control-Allow-Origin: *  
  
  
Access-Control-Allow-Methods: GET  
  
  
Access-Control-Max-Age: 60  
  
  
Content-Encoding: gzip  
  
  
Content-Length: 0  
  
  
Connection: Keep-Alive  
  
  
Content-Type: text/text  
 
 

The content of these Access headers is added to the backend of the server. It tells the browser that in the next 60 seconds, all the domains can Access the resource through the GET method. then the browser automatically resends the real GET request and returns the corresponding result.

Note that this process is automatically implemented by the browser. Is this great? Some header information settings are as follows:

 
 

  
  
Access-Control-Allow-Origin: <origin> | * // authorized source Control
  
  
Access-Control-Max-Age: <delta-seconds> // authorization time
  
  
Access-Control-Allow-Credentials: true | false // determines whether to enable Cookie submission with Ajax.
  
  
Access-Control-Allow-Methods: <method> [, <method>] * // HTTP Method that allows the request
  
  
Access-Control-Allow-Headers: <field-name> [, <field-name>] * // Control which Headers can send real requests
 
 

Another thing that requires collaboration between front-end engineers is cookie transfer. By default, CORS is used to prevent cookie transfer. generally, adding a cookie to the header is forbidden by the browser and an error is reported. as shown above, the server adds a response header, Access-Control-Allow-Credentials, to Control whether to Allow Cookie submission.

In Angular, we need to make some settings for the purpose:

 
 

  
  
$ Http. post (url, {withCredentials: true ,...})
  
  
// Or
  
  
$ Http ({withCredentials: true,...}). post (...)
  
  
// Or
  
  
. Config (function ($ httpProvider ){
  
  
$ HttpProvider. defaults. withCredentials = true;
  
  
}
 
 

If it is jQuery, you need to set it as follows:

 
 

  
  
$.ajax("www.cros.com/api/data", {  
  
  
  type: "GET",  
  
  
  xhrFields: {  
  
  
    withCredentials: true 
  
  
  },  
  
  
  crossDomain: true,  
  
  
  success: function(data, status, xhr) {  
  
  
  }  
  
  
}); 
 
 

After the CORS process is described, find an image on the Internet:

CORS Classification

If you carefully observe the browser behavior, you will find that not all cross-origin requests will send the OPTIONS request. Isn't it strange? This involves the CORS classification, simple requests, and complex requests.

The HTTP header usually contains the following content:

 
 

  
  
Accept
  
  
Accept-Language
  
  
Content-Language
  
  
Last-Event-ID
  
  
The value of Content-Type is only one of the following:
  
  
Application/x-www-form-urlencoded
  
  
Multipart/form-data
  
  
Text/plain
 
 

The HTTP method is one of HEAD, GET, and POST, and the HTTP header contains as shown above. any request that does not meet these two requirements is a complex request. for example, sending PUT, DELETE, and other HTTP actions, or Content-Type: application/json Content.

Only complex requests include the "pre-check" action. In addition, Access-Control-Max-Age should also affect the sending of OPTIONS requests.