The occurrence of cross-domain warning

If you do some before and after the end of the separation project, due to the back-end service address and service address at this time where the front end where not the same, you may experience problems a browser request is intercepted, the browser detects that the current page-initiated request does not belong to the current domain will be blocked, because the "same origin policy" browser.

So, what are homologous strategy?
Origin policy used to limit the page to initiate a different domain (source) requests for increased security requests.
If two pages of protocol, port, IP address (domain name) are the same, then that is homologous to two pages, that is, the same domain.

Example:
In http://192.168.10.1:8080/index.html as control source,
http://192.168.10.1:8080/auth/login.html and which is homologous ;
http://192.168.10.1:8181 /index.html and it is not homologous , because the port is not the same;
http://192.168.10.30:8080/index.html and it is not homologous , because the IP address is not the same.

Some people may ask, since the domain is not the same intercepts why I used xxxCDN css file, this request was not intercepted it?
Here we must mention some, not all cross-domain requests will be intercepted.
1. Normal browser does not intercept a number of cross-domain resource embedded in the request.
This so-called embedded resources, is similar to the <img>label src, <script>the src, <link>such a request href, such a request is a request directly embedded resources to your page. So you use a cdn css file will not be blocked. [So kind of way is this to embed way to solve the problem of cross-domain]
2. The browser typically does not intercept a number of requests to write cross-domain resources.
This so-called cross-domain resources to write, so-called hyperlinks request, page redirects, form a non XMLHttpRequest way of submission (common form form submission) and so on.
3. The browser will usually read intercepts the request cross-domain resources.
XMLHttpRequest to submit the form, XMLHttpRequest request resources, common in asynchronous operation []

In addition, to re-emphasize that the same-origin policy is a security policy browsers . So if you can direct them without the aid of browser software by postman to send http request to send the request, then it is not blocked by your cross-domain requests.

An example of a test that can be used:
(When I deployed the following html files to a web server (tomcat, apache, etc.) in time, this time in the pages of my domain should be the address of the machine localhost:80, according to me at this time the above three areas to test whether the browser interception. the result is that only the last one is intercepted. [Do not deploy directly open the page, otherwise it's just a regular local file, not a network file, then browse does not think this is a domain])

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8" />
    <title>用于测试跨域</title>

</head>
<body>
    <!-- 跨域资源嵌入,允许 -->
    <img src="https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1565884598468&di=bb6ccc7a3280b183e4e13c852bc8353c&imgtype=0&src=http%3A%2F%2Fs04.lmbang.com%2FM00%2FCA%2FDE%2FDpgiA1uPAOKAXmJfAADir1hWa-A750.gif" alt="">

    <!-- 跨域资源写操作，允许 -->
    <a href="http://www.baidu.com">百度</a>

    <form action="http://www.baidu.com" method="post" >
        用户名：<input type="text" name="username" value="" placeholder="">
        <input type="submit" name="提交" value="提交">
    </form>

    <!-- 跨域资源读操作，禁止 -->
    <button onclick="senddata()">XMLHttpRequest请求</button>

    <script type="text/javascript">
    var xmlhttp=new XMLHttpRequest();

    function senddata(){
        xmlhttp.open("GET","https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1565884598468&di=bb6ccc7a3280b183e4e13c852bc8353c&imgtype=0&src=http%3A%2F%2Fs04.lmbang.com%2FM00%2FCA%2FDE%2FDpgiA1uPAOKAXmJfAADir1hWa-A750.gif",true);
        xmlhttp.send();
    </script>
</body>
</html>

supplement:

Why the browser will use the same origin policy? It wants to solve the problem?
First, let's talk about it cookie, cookie mainly used to store some data some of the current site, in some old web development and some will put the user login information stored in the cookie. So, from a security point of view, you should want cookie on your site can not be another site to use (or else the data in the cookie is very easy for someone else to steal), so this introduces the concept of domain by domain to limit the use of resources, to intercept cross-domain resource requests.

How to allow cross-domain

There are many means to resolve cross-domain, but a common problem for cross-domain call interface is CORS

HEARTS

How to allow cross-domain, one solution is to target domain to tell the requester to request a permit What is the source domain , the browser will know whether to allow the B domain A domain initiates a request.
CORS ( "Cross-Origin Resource Sharing" (Cross-origin resource sharing)) is one such means of settlement.

CORS make the browser before initiating a request to the destination domain to initiate a request OPTIONS way to the destination domain to obtain information purposes domains, such as access to information on what the purpose of allowing the domain to the domain requested.

At this object is usually required to add the following information in the response header:

Access-Control-Allow-Origin: what used to declare a domain can initiate a request to the current domain.
Access-Control-Allow-Methods: used to declare what type of request can be initiated to the current domain.
Access-Control-Max-Age: this is used to specify valid OPTIONS request, in seconds, during which not issue another OPTIONS request.
Access-Control-Allow-Headers: to allow you to have any special request up to initiate additional requests. [Some projects will separate the front and rear end into the token header, this time the request will need to head Access-Control-Allow-Headers to declare a]
[after the OPTIONS request is successful, the browser will record the information for determining whether the request sent to the destination domain needs to intercept. If the OPTIONS request fails, then it had to be initiated by a request will not be sent. ]

But sometimes send the request will not trigger OPTIONS request. If the request meets the following conditions, then:
the way 1. The request is a GET, POST or HEAD.
2. Request heads belonging Accept, Accept-Language, Content- Language, Content-Type, Viewport-Width.
3. Content-Type header request belongs application / x-www-form- urlencoded, multipart / form-data, text / plain one.

This request is also referred to as "a simple request."

Simple request tests:

The following examples can be used to test whether a simple and non-simple request OPTIONS request will be issued

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8" />
    <title>用于测试简单请求</title>
</head>
<body>
    <button onclick="senddata()">XMLHttpRequest请求</button>
    <script type="text/javascript">
    var xmlhttp=new XMLHttpRequest();

    function senddata(){
        xmlhttp.open("GET","https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1565884598468&di=bb6ccc7a3280b183e4e13c852bc8353c&imgtype=0&src=http%3A%2F%2Fs04.lmbang.com%2FM00%2FCA%2FDE%2FDpgiA1uPAOKAXmJfAADir1hWa-A750.gif",true);
xmlhttp.send();

        //如果你有一个可以用来测试的接口，可以尝试把这一段注释了，来测试是否发送OPTIONS请求。
  //       xmlhttp.open("POST","http://localhost:8080/hello",true);
         //下面通过加了一个请求头，使得这个请求不是一个不发OPTIONS的请求。
        // xmlhttp.setRequestHeader("Content-Type", "application/json")
  //       xmlhttp.send();
    }
    </script>
</body>
</html>

Back-end processing

The following Spring MVC-based framework to illustrate how the back-end Return CORS response headers (Note: In the spring mvc, you can directly use @CrossOriginsimple CORS response headers to return).
Distal request test code:

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8" />
    <title>用于测试OPTIONS</title>
</head>
<body>
    <!-- 跨域资源读操作，禁止 -->
    <button onclick="senddata()">XMLHttpRequest请求</button>

    <script type="text/javascript">
    var xmlhttp=new XMLHttpRequest();

    function senddata(){
        //如果你有一个可以用来测试的接口，可以尝试把这一段注释了，来测试是否发送OPTIONS请求。
        xmlhttp.open("POST","http://localhost:8080/hello",true);
         //下面通过加了一个请求头，使得这个请求不是一个不发OPTIONS的请求。
        xmlhttp.setRequestHeader("Content-Type", "application/json")
        xmlhttp.send();
    }
    </script>
</body>
</html>

When we do not have to deploy interface, we can see that the page is made a OPTIONS request:

Also, the browser console also suggest the following information:

When we deployed the interface, we try not to return to formal CORS response headers.

Since there is no return CORS response headers, so there is no OPTIONS request to the appropriate information CORS, the request is intercepted, it will alert the two packets of FIG.