CORS cross domain (front-end + back-end code example explanation)

CORS cross-domain principle

The cross-domain principle of CORS is that the browser and server make some conventions and restrictions through some HTTP protocol headers. You can see HTTP- Access Control (CORS)

Protocol headers associated with cross-domain

The code examples

So I’ve written a little demo here, step by step. The directory is as follows:

. ├ ─ ─ the README. Md ├ ─ ─ client │ ├ ─ ─ index. The HTML │ └ ─ ─ request. Js └ ─ ─ server ├ ─ ─ pom. The XML ├ ─ ─ server - web │ ├ ─ ─ pom. The XML │ ├ ─ ─ Server - web. On iml │ └ ─ ─ the SRC │ └ ─ ─ the main │ ├ ─ ─ Java │ │ └ ─ ─ com │ │ └ ─ ─ example │ │ └ ─ ─ cors │ │ ├ ─ ─ constant │ │ │ └ ─ ─ Constants. Java │ ├─ Controller │ ├─ Java │ ├─ ├─ Java │ ├─ Java │ ├─ Java │ ├─ Java │ ├─ Resources │ │ └ ─ ─ the config │ │ └ ─ ─ applicationContext - core. XML │ └ ─ ─ webapp │ ├ ─ ─ WEB - INF │ │ ├ ─ ─ the dispatcher - servlet. XML │ │ ├ ─ ├ ─ sci-1.txt ├ ─ sci-1.txt ├ ─ sci-1.txtCopy the code

• Client: Front-end, simple Ajax requests

In the client folder, start the static server, front page via http://localhost:8000/index.html access:

anywhere -h localhost -p 8000
Copy the code

• Server: Java project, SpringMVC

Local start tomcat in IntelliJ IDEA, set up the host: http://localhost:8080/, the server-side data via http://localhost:8080/server/cors requests.

Because of the different port numbers of the front-end and back-end, there are cross-domain restrictions. Here, CORS is used to solve the problem that cross-domain data cannot be requested through Ajax.

There is no case where cross domains are allowed

This is a situation where the front end does nothing and the server side does nothing.

Client: After the request is successful, the data is displayed on the page

new Request().send('http://localhost:8080/server/cors', {success: function(data){
		document.write(data)
	}
});
Copy the code

Server:

@Controller
@RequestMapping("/server")
public class CorsController {
    @RequestMapping(value="/cors", method= RequestMethod.GET)
    @ResponseBody
    public String ajaxCors(HttpServletRequest request) throws Exception{
        return "SUCCESS"; }}Copy the code

In your browser’s address bar enter http://localhost:8080/server/cors direct request to the server, you can see return results: ‘SUCCESS’

In your browser’s address bar enter http://localhost:8000/index.html, web pages from different domain send an ajax request to the Server. Several aspects can be seen:

As you can see from network, the request returned normal.

However, there is no content in Response and Failed to load Response data is displayed.

And the console reported an error:

Conclusion:

1, the browser request is sent, the server will return the correct, but we can not get the response content

2, the browser console complains tips can do, and prompt very understand: XHR cannot request http://localhost:8080/server/cors, requested resource is not set in the response header Access – Control – Allow – Origin, Origin: http://localhost:8000 does not allow cross-domain requests.

The next step is to set the access-Control-Allow-Origin header when the server responds to a cross-domain request

Simple request vs. precheck request

Access-control-allow-origin a simple request can be made by setting the response header access-Control-Allow-Origin on the server.

What kind of request is a simple request? What is the equivalent of a simple request? What’s different about the way you solve cross-domains?

A simple request can be considered if it meets the following conditions:

1. Use one of the following HTTP methods

-get-head-post, and the content-type value is one of the following: -text/plain-multipart/form-data-application /x-www-form-urlencodedCopy the code

And the request header contains only the following

-accept-accept-language-content-language-content-type -dpr - Downlink - save-data - viewport-width - DPR - Downlink - save-data - viewport-width -  WidthCopy the code

If the request does not meet the preceding requirements, the browser must send a precheck request before sending a formal request. The precheck request is sent in the OPTIONS method. The browser can determine whether to send the precheck request based on the request method and request header.

For example, the Client sends the following request:

new Request().send('http://localhost:8080/server/options', {method: 'POST'.header: {
		'Content-Type': 'application/json'  // Tell the server what type of data is actually being sent
	},
	success: function(data){
		document.write(data)
	}
});
Copy the code

Controller for Server handling requests:

@Controller
@RequestMapping("/server")
public class CorsController {
    @RequestMapping(value="/options", method= RequestMethod.POST)
    @ResponseBody
    public String options(HttpServletRequest request) throws Exception{
        return "SUCCESS"; }}Copy the code

Header is inserted in the request header, ‘Content-Type’: ‘application/json’. The browser will issue a precheck request with the OPTIONS method. The browser will add the following headers to the request:

Access-Control-Request-Headers:content-type
Access-Control-Request-Method:POST
Copy the code

The purpose of this precheck Request is to tell the server that I will send a Request Header with a Content-type in the POST method in the following Request and ask the server whether to allow it. .

Here the server has not done anything to allow this request, so the browser console is reporting an error:

The server does not tell the browser to Allow content-type in the response to the pre-check request. That is, the server needs to set access-Control-allow-headers to Allow the browser to send requests with content-type.

Add access-control-allow-headers to the Server filter.

public class CrossDomainFilter implements Filter{
    public void init(FilterConfig filterConfig) throws ServletException {}
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HttpServletResponse resp = (HttpServletResponse)servletResponse;
        resp.setHeader("Access-Control-Allow-Origin"."http://localhost:8000");
        resp.setHeader("Access-Control-Allow-Headers"."Content-Type");
        filterChain.doFilter(servletRequest,servletResponse);
    }
    public void destroy(a) {}}Copy the code

You can see that the request succeeded

The first time the precheck request is sent, the browser sets the request header:

Access-control-request-headers :content-type // Request Headers added to the Request access-Control-request-method :POST // Cross-domain Request MethodCopy the code

The server sets the response header:

Access - Control - Allow - Headers: the content-type / / Allow the header Access - Control - Allow - Origin: / / http://localhost:8000 Allow cross-domain sourceCopy the code

Access-control-allow-methods can also be set to limit client request Methods.

When the precheck request succeeds, the browser issues a second request, which is the actual request for data:

You can see that the POST Request is successful. The access-Control-request-headers and access-Control-request-method are not set for the second Request.

But there is a problem here. When you need to precheck the request, the browser will issue two requests, one OPTIONS and one POST. Both times the data was returned. In this way, if the server logic is complicated, for example, to search for data in the database, the logic from the Web layer and service to the database will go through twice, and the browser will get the same data twice. Therefore, the filter of the server can be changed. After setting the cross – domain request response header, it returns directly without following the logic.

public class CrossDomainFilter implements Filter{
    public void init(FilterConfig filterConfig) throws ServletException {}
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
        HttpServletResponse resp = (HttpServletResponse)servletResponse;
        resp.setHeader("Access-Control-Allow-Origin"."http://localhost:8000");
        resp.setHeader("Access-Control-Allow-Headers"."Content-Type");   
        // The OPTION request is returned directly
        HttpServletRequest req = (HttpServletRequest) servletRequest;
        if (req.getMethod().equals("OPTIONS")) {
            resp.setStatus(200);
            resp.flushBuffer();
        }else{ filterChain.doFilter(servletRequest,servletResponse); }}public void destroy(a) {}}Copy the code

Conclusion:

1. If the content-Type of the response header for a POST request is set to some value, or if the response header for a custom request is set to some value, the browser will first send a precheck request using OPTIONS and set the corresponding request header.

2. The server still returns normally, but if no corresponding response header is set in the response header of the precheck request, the precheck request will not pass and the second request will not be issued to obtain data.

3, the server set the corresponding response header, the browser will send a second request, and the data returned by the server spit out, we can get the response content

other

Internet Explorer has no permission for cross-domain access

Prompt no permissions when sending ajax requests across domains. By default, Internet Explorer restricts cross-domain access. You need to remove restrictions in your browser Settings. Methods: Settings > Internet Options > Security > Custom Levels > Find Others in Settings – Enable Access to data sources by domain in Others.

Did you get anything? See this one? You may not know the wild history of JavaScript modularity