I. Background
Because it is separated from the front and rear ends of development, so cross-domain problems have been encountered, but the solution had previously been used by the code control settings response.setheader to solve, which is a result of the largest in the Baidu search to get the most of blog articles are using this program to solve the problem, it is also true that has been at work until I recently developed a new cross-domain project encountered problems again, clearly has set up a response or will happen, I began to delve into, so he With about content, which is again really solve the problem of cross-domain research results on Baidu is not parroting copy and paste come.
Second, generate cross-domain problems
Cross-domain problems often occur at the trailing edge separating the development of the former scenario, the cross-domain issues will determine under what circumstances it occurred? That is, when the front and rear ends of different sources, homologous need to meet three conditions:
1) the same protocol ( HTTP HTTPS this)
2) the same domain name
3) the same port
Often the scene before and after the end though we deployed in the same server, but are generally placed in the front NGINX back end on tomcat port is different, so he produced the same protocol, the same domain name but different ports of cross-domain problem, this said at a digression, we want to avoid cross-domain issues are on the front and rear end with a tomcat on the line.
Three, CORS two request methods
There are several options to solve cross-domain, generally the most commonly used it is CORS , because this program does not require changes to the front end, in fact, mentioned earlier response.setheader way is CORS , this article only for CORS to explain.
CORS request into two categories: a simple request ( Simple Request ) and non-simple request ( Not-SO-Simple Request ), as long as the following two conditions are met, it belongs to a simple request:
( 1) the request is one of the following three methods:
HEAD
GET
POST
( 2 ) the HTTP header information does not exceed the following fields:
Accept
Accept-Language
Content-Language
Last-Event-ID
The Type-the Content : the value is limited to three file application / X-WWW-form-urlencoded , multipart / form-Data , text / Plain
Does not meet the above conditions belong to non-simple request, I call complex requests.
Practical solutions to four two ways request
Recalling the context of previous cross-domain way to solve why it will not work now? The reason is that out of this in a different way request, previous projects are simple request, and now the project is complex requests, solutions are not the same,
Simple request
Simple requests can enter directly to the interface in its internal logic execution, executing the normal response is returned, but if the result desired response is received correctly, it is necessary in the cross-domain response permission in advance plus Access-Control-the Allow , response header is the Response Header , cross-domain license on several parameters are:
Etc., which must be a simple request parameter is Access-Control-the Allow-Origin (permit cross-domain source), the role of other parameters, please inquire on their own, not to carry out here, so cross-domain problem solving requires only a simple request in response header plus Access-Control-Allow-Origin parameters, examples:
String origin = request.getHeader("Origin");
if (origin == null) {
origin = request.getHeader("Referer");
}
response.setHeader("Access-Control-Allow-Origin", origin);
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
response.setHeader("Access-Control-Allow-Headers", "*");
Complex requests
Complex requests not directly into the internal logic of the interface to perform, but will first send OPTIONS preflight request, if the request can not be responded properly preflight, will not enter into the interior of the method execution logic, the process provided a simple request code the method of response headers do not apply, the request simply can not reach internal method, so before we execute the code in the method needs to handle the response header, it is not difficult to think of a good solution to the problem will be able to use interceptors
Treatment principle complex request with a simple request is the same, as long as the set response headers on it, except that which layer is provided in response to head, of course, the use of complex requests for a simple request approach is also applicable, two complex request processing ways:
1) use of interceptors, in response to the first set, wherein the cross-domain parameters must still Access-Control-the Allow-Origin , if there is a change request header words are needed to bring Access-Control-the Allow-Headers (permit request header), in fact cause most complicated scene change request because the request header, sending json need to set the request header data contentType = the Application / json . While the general scenario requires only two parameters is enough but it is recommended that all parameters have to write the whole, the reasons can see below. Interceptor example:
public class HeadersCORSFilter
implements Filter
{
public void destroy() {}
public void doFilter(ServletRequest request, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException {
HttpServletResponse response = (HttpServletResponse)servletResponse;
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers", "*");
response.setHeader("Access-Control-Allow-Credentials", "true");
chain.doFilter(request, servletResponse);
}
public void init(FilterConfig arg0) throws ServletException {
System.out.println ( "interceptor initialization");
}
}
2) Use @CrossOrigin , spring can be a popular part of the reason I believe that there is merit the label, the use of spring labels can help us write code more elegantly simple, so when I learned that there are problems to solve cross-domain @CrossOrigin the label also milli do not hesitate to use, according to most people say on Baidu plus method above @CrossOrigin tag can solve the immediate problem, then bad will add @CrossOrigin ( Origins = "xx") specified on the permit cross-domain source can, but unfortunately, no matter what kind of method I have no role, so in-depth research @CrossOrigin , view its source code found that in addition allow-methods to the four other parameters are all default values (Note: here based org.springframework 4.23 version)
So try to increase the allow-methods attribute:
@CrossOrigin(methods = {RequestMethod.POST})
The results really worked, the perfect solution to cross-domain problem. Some say that the Internet is also in requestmapping specify the method @RequestMapping (= Method, RequestMethod.GET) , the principle is the same, because @CrossOrigin default support @RequestMapping statement of all types of sources and methods.
V. Conclusion
Generate cross-domain problems do not worry, the first cross-domain analysis of the need to avoid the problem, the workaround is to the front and rear end in the same source, unable to avoid, and then request the analysis is simple or complex requests, to avoid the need for complex requests, to avoid the method is simple and complicated request is a request, using a request is not a request to change the way out of range of the first class, it can not avoid complex requests.