Separate front and rear ends java, jwt project CORS cross-domain, a simple request to resolve the non-cross-domain problem, compatibility problems

Case Description:

Recently there has been cross-domain problems in the deployment of a separate front and rear end of the project *

Jwt project uses for authentication, it is necessary to carry front-end request to initiate a request TOKEN * The request brought the token can not be sent to the back-end success,

After using cross-domain compatibility problems: Chrome, Firefox browser normal, while IE or cross-domain error report

First, the cross-domain problems in the project can use CORS solve

method one

@CrossOrigin

In each controller class plus

 

Second way  directly added to the configuration of the spring-mvc

    <! - Cross-Domain Interface Configuration ->

    <mvc:cors>

        <mvc:mapping path="/**"

                     allowed-origins="*"

                     allowed-methods="POST, GET, OPTIONS, DELETE, PUT"

                     allowed-headers="Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With"

                     allow-credentials="true" />

    </mvc:cors>

Three ways can interceptor to the increase header response

        response.setHeader("Access-Control-Allow-Origin", "*");

        response.setHeader("Access-Control-Allow-Credentials", "true");

        response.setHeader("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS");

        response.setHeader("Access-Control-Max-Age", "86400");

        response.setHeader("Access-Control-Allow-Headers", "Authorization,Overwrite, Destination, Content-Type, Depth, User-Agent, Translate, Range, Content-Range, Timeout, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control, Location, Lock-Token, If");

 

The above three simple way for the average effective cross-domain requests to meet most needs. But when the non-cross-domain requests simple case, there will be a problem, we need to do some adjustments.

 

Second, the need for complex requests options preflight process the request

 

Before and after the end of the separation project, the browser requests would often non-simple cross-domain requests, this request will be sent twice, first by the browser to initiate a request preflight request options, and then returned to the server based on the content of the the browser determines whether to allow the request to the server, the second method is the get, post or put the like, and no data is returned first, second before returning to normal data.

 

So we will encounter: we are dealing with token interceptor (non-simple case, the authorization header carries a token for authentication), receiving the option when will the preflight request as a normal request, but when the options can not be requested in the header carrying token, so the rear end of the first request will fight back, leading to a second request can not be launched properly.

 

Non simple cases (including one of the following):

  1. Request mode: the PUT, the DELETE
  2. Custom header field
  3. Send json format data
  4. Before the formal communication, the browser will first send OPTION request, pre-screening, this time the request is called "preflight request"
  5. After a successful server response preflight request, it will send real request, and carries real data

 

Solution of the options by the request directly to the rear end (200, 204 simply return to the browser i.e. the server determines permission request)

Add a CorsInterceptor

public class CorsInterceptor implements HandlerInterceptor {

// use the third approach, a CORS configuration

        response.setHeader("Access-Control-Allow-Origin", "*");

        response.setHeader("Access-Control-Allow-Credentials", "true");

        response.setHeader("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS");

        response.setHeader("Access-Control-Max-Age", "86400");

        response.setHeader("Access-Control-Allow-Headers", "Authorization,Overwrite, Destination, Content-Type, Depth, User-Agent, Translate, Range, Content-Range, Timeout, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control, Location, Lock-Token, If");

        if(HttpMethod.OPTIONS.toString().equals(httpServletRequest.getMethod())){

            response.setStatus(HttpStatus.NO_CONTENT.value());

            System.out.println ( "request options are skipped");

            return false;

        }

        return true;

    }

}

  

In the spring-mvc loaded in this prior CorsInterceptor, placed in the processing token

        <mvc:interceptor>

            <mvc:mapping path="/**" />

            <bean class="cn.gdyvc.interceptor.CorsInterceptor" />

        </mvc:interceptor>

Three, CORS browser compatibility issues

 

Finally, the deployment is complete, but Chrome, Firefox browser normal, but IE still reported cross-domain error, and Internet Explorer encounters a problem CORS Access-Control-Allow-Methods of

The beginning of the cross-domain configuration settings of the Internet Access-Control-Allow-Headers corresponds to "*", and Ie * is not able to respond , it is necessary to columns of header listed separately

 

 

 

Reference links:

https://www.jianshu.com/p/5c637bfcc674

https://stackoverflow.com/questions/51857247/ie-cors-access-control-allow-headers-error-even-though-headers-are-specified

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers

 

Guess you like

Origin www.cnblogs.com/liqiujiong/p/12370207.html