A perfect solution for accessing cookies cors across domains

There used to be a very old article online turned a lot, including now if you Baidu "Cross-domain" this keyword, the first several recommended are "JavaScript cross-domain summarization and solution." Look at the feeling, it's a little old-fashioned, Some of the solutions, such as Document.domain and IFRAME, are "ugly" and feel no longer applicable to some projects now.

Take IFrame as a front-end engineer, I hate this kind of thing. It not only increases the high performance load, but also is not good for control.

The way to achieve cross-domain in angular applications is relatively simple, basically in two ways. One is the JSONP, the other is through the cors. The former is relatively old method, the latter I feel more give a little, so this article is mainly about angular how to cooperate with Cors Cross-domain.

It is a principle to proceed to angular cross-domain if you can not use JSONP as much as possible. In any case, the script's label embedding feels a little low.

Angular is highly admired for the separation of the front and back ends, so the cross-domain implementation becomes a problem. This has to be said the front-end technical limitations, even the relatively useful JSONP for non get requests are powerless, because it is essentially through the script to get some resources.

Jsonp This only get limit, in angular the restful style interface of the API scenario, it completely restricts its use, always can not discard post and put those regardless. and JSONP error handling is weak, Disappointments. In short, front-end implementations have a wide range of limitations, such as document.domain can only be used for the same primary domain, different subdomains.

So in summary, although the front end has a variety of ways to deal with Cross-domain, but many but not fine, the shortcomings are more obvious. A relatively better way is to get involved with the backend, which is not only more adaptable, but also a front-end that sends a normal AJAX request. This technique is called cors.

Cross-origin Resource sharing Cross-domain resource sharing should be considered the most recommended cross-domain processing scenario. Not only for all kinds of method, but also more convenient and simple. Of course, the only thing that hangs like this is the modern browser support, IE8 the old relic. .

Cors Realization Principle

Although the Cross-domain implementation across the Cors is basically implemented by the backend, it is the front end of a given force. Still have to master this principle so that when you encounter the unreliable backend, it is not ... You know

The nature of Cors let the server through the new response header Access-control-allow-origin, through HTTP to achieve resource sharing, so that each requested service directly return resources. It uses HTTP interaction to determine whether the request source is eligible to request the resource, and Controls access to the resource by setting the HTTP header.

The specific process is such that the front-end sends a normal request:

$http. Get (' Www.cros.com/api/data ', {params:{

Name: ' Stubborn Shi '

}})

The back end sets the header for response:

Access-control-allow-origin: "*"

Access-control-allow-methods: "Get"

Access-control-max-age: "60"

And then you look at the behavior of the browser and you find something interesting, the browser discovers that this is a cross-domain request without your intervention. So instead of sending a GET request directly, it sends a options request asking if the resource can be accessed across domains, a process we can call a "prefetch."

Then we saw that the response of options returned a message similar to the following:

http/1.1 OK

Date:mon, 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 contents of these access headers here are the server backend Plus, which tells the browser that all domains can access the resource across the domain through the Get method in the next 60 seconds. Then the browser automatically sends the real GET request again and returns the corresponding result.

Note that this process is automatically implemented by the browser, which is not very good. Some header information is set as follows:

Access-control-allow-origin: <origin> | *//Authorized Source Control

Access-control-max-age: <delta-seconds>/Authorized Time

Access-control-allow-credentials:true | False//control whether to open the cookie submission method with Ajax

Access-control-allow-methods: <method>[, <method>]*//Allow requested HTTP method

Access-control-allow-headers: <field-name>[, <field-name>]*//control which headers can send a real request

Here's another place where the front-end engineers collaborate is the passing of cookies, which by default do not pass cookies in such a way that it is cors. Generally mandatory to add cookies to the header, will also be rejected by the browser and an error. It's seen on the server side by adding a response header, access-control-allow-credentials to control whether the cookie is allowed to commit.

In angular we need to make some settings to achieve the goal:

$http. Post (URL, {withcredentials:true, ...})

Or

$http ({withcredentials:true, ...}). Post (...)

Or

. config (function ($httpProvider) {

$httpProvider. Defaults.withcredentials = true;

}

If it is jquery, set the following:

$.ajax ("Www.cros.com/api/data", {

Type: "Get",

Xhrfields: {

Withcredentials:true

},

Crossdomain:true,

Success:function (data, status, XHR) {

}

});

Cors Process description completed, find a picture on the Internet:

Classification of Cors

If you look closely at the behavior of your browser, you will find that not all Cross-domain requests will send the options request. Is it a bit odd, this involves cors classification, simple requests, and complex requests.

The header of HTTP usually contains the following:

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 the Head,get,post, and the header of HTTP is included as shown above. Any request that does not meet both requirements is a complex request. such as sending Put,delete HTTP actions, or Content-type: Application/json's content.

Only complex requests contain a "prefetch" action, and access-control-max-age should also affect the delivery of the options request.

Transferred from http://my.oschina.net/blogshi/blog/303758