Thoroughly understand cross-domain issues SpringBoot helps you unimpeded

Environment: SpringBoot2.7.16

1. Introduction

Cross-origin resource sharing (CORS, or more colloquially translated as cross-domain resource sharing) is a mechanism based on HTTP headers that allows the server to indicate other sources (domains, protocols or ports) besides its own, so that the browser allows these sources to access and load its own resources. Cross-origin resource sharing also uses a mechanism to check whether the server will allow the real request to be sent. The mechanism initiates a "pre-check" request to the cross-origin resource hosted by the server through the browser. In the pre-check, the header sent by the browser indicates the HTTP method and the header that will be used in the real request.

Cross-origin HTTP request example: JavaScript code running on https://www.a.com uses XMLHttpRequest to initiate a request to https://www.b.com/data.json.

For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts. For example, XMLHttpRequest and Fetch APIs follow the same-origin policy. This means that web applications using these APIs can only request HTTP resources from the same domain that loaded the application, unless the response message contains the correct CORS response header.

picture

When is CORS required?

This cross-origin sharing standard allows cross-site HTTP requests in the following scenarios:

• A cross-origin HTTP request initiated by XMLHttpRequest or Fetch API.
• Web fonts (using cross-origin font resources via @font-face in CSS), so websites can publish TrueType font resources and only allow authorized websites to make cross-site calls.
• WebGL textures.
• Use drawImage() to draw the image or video screen to canvas.
• CSS graphics from images (en-US).

The Cross-Origin Resource Sharing standard adds a set of HTTP header fields that allow servers to declare which origins have access to which resources through the browser. In addition, the specification requires that for HTTP request methods that may have side effects on server data (especially HTTP requests other than GET, or POST requests with certain MIME types), the browser must first use the OPTIONS method to initiate a preflight request to find out whether the server allows the cross-origin request. The server will only initiate the actual HTTP request after confirming that it is allowed. In the response to the preflight request, the server can also notify the client whether it needs to carry identity credentials (such as cookies and HTTP authentication-related data).

Failed CORS requests will generate errors, but for security reasons, you cannot know exactly where the problem occurred at the JavaScript code level. You can only check the browser console to find out where the error occurred.

What is a preflight request?

A CORS preflight request is used to check whether the server supports CORS, or cross-origin resource sharing. It is usually an OPTIONS request with the following HTTP request headers: Access-Control-Request-Method and Access-Control-Request-Headers, as well as an Origin header. When necessary, the browser will automatically issue a preflight request; so under normal circumstances, front-end developers do not need to issue such a request themselves.

For example, a client might initiate a preflight request to the server to ask if it is OK to initiate a DELETE request before actually sending a DELETE request:

 OPTIONS /resource/foo Access-Control-Request-Method: DELETE Access-Control-Request-Headers: origin, x-requested-with Origin: https://foo.bar.org

If the server allows it, it will respond to the preflight request, and its response header Access-Control-Allow-Methods will include DELETE:

 HTTP/1.1 200 OK Content-Length: 0 Connection: keep-alive Access-Control-Allow-Origin: https://foo.bar.org Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE Access-Control-Max-Age: 86400

HTTP Headers for CORS:

• Access-Control-Allow-Origin indicates whether the response resource can be shared with the given origin.
• Access-Control-Allow-Credentials indicates whether the response to a request can be made public when the credentials flag of the request is true.
• Access-Control-Allow-Headers is used in the response to a preflight request to indicate which HTTP headers can be used in the actual request.
• Access-Control-Allow-Methods specifies which HTTP methods are allowed to access the requested resource in the response to a preflight request.
• Access-Control-Expose-Headers indicates which headers can be exposed as part of the response by listing the names of the headers.
• Access-Control-Max-Age indicates how long the results of the preflight request can be cached.
• Access-Control-Request-Headers is used to initiate a preflight request to tell the server which HTTP headers will be used in the formal request.
• Access-Control-Request-Method is used to initiate a pre-check request to inform the server which HTTP request method will be used for the formal request.
• Origin indicates the source from which the request to obtain the resource was initiated.
• Timing-Allow-Origin specifies specific origins to allow access to property values ​​provided by the Resource Timing API functionality that would otherwise be reported as zero due to cross-origin restrictions.

After having a general understanding of CORS, let's introduce how to solve cross-domain problems in SpringBoot.

2. Practical Examples

Spring MVC HandlerMapping implementations provide built-in support for CORS. After successfully mapping a request to a handler, the HandlerMapping implementation checks the CORS configuration for the given request and handler and takes further action. Preflight requests are handled directly, while simple and real CORS requests are intercepted, validated, and the required CORS response headers are set.

2.1 @CrossOrigin

The @CrossOrigin annotation enables cross-origin requests to annotated controller methods, as shown in the following example:

 @RestController @RequestMapping("/accounts") public class AccountController { @CrossOrigin @GetMapping("/{id}") public Account retrieve(@PathVariable Long id) { // ... } @DeleteMapping("/{id}") public void remove(@PathVariable Long id) { // ... } }

By default, @CrossOrigin allows:

• All requests come from origins.
• All request headers.
• All HTTP methods that controller methods are mapped to.

Note: allowCredentials is not enabled by default, as it establishes a trust level that exposes sensitive user-specific information (such as cookies and CSRF tokens), and should only be used where appropriate. When enabled, allowOrigins must be set to one or more specific domains (but not the special value "*"), or the allowOringPatterns attribute can be used to match a dynamic set of origins.

maxAge defaults to 30 minutes.

@CrossOrigin is also supported at the class level and is inherited by all methods, as shown in the following example:

 @CrossOrigin(origins = "https://www.pack.com", maxAge = 3600) @RestController @RequestMapping("/accounts") public class AccountController { @GetMapping("/{id}") public Account retrieve(@PathVariable Long id) { // ... } }

You can use @CrossOrigin at the class level and at the method level, as shown in the following example:

 @CrossOrigin(maxAge = 3600) @RestController @RequestMapping("/accounts") public class AccountController { @CrossOrigin("http://www.pack.com") @GetMapping("/{id}") public Account retrieve(@PathVariable Long id) { // ... } }

2.2 Global Configuration

In addition to fine-grained controller method-level configuration, you can also set global CORS configuration. You can set URL-based CorsConfiguration mappings individually on any HandlerMapping.

By default, the global configuration enables the following features:

• All requests originate from.
• All request headers.
• GET, HEAD, and POST methods.

 @Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOrigins("http://www.pack.com") .allowedMethods("PUT", "DELETE") .allowedHeaders("header1", "header2", "header3") .exposedHeaders("header1", "header2") .allowCredentials(true).maxAge(3600) ; } }

2.3 CORS Filter

CORS support can be applied via the built-in CorsFilter.

Note: If you try to use CorsFilter with Spring Security, remember that Spring Security has built-in support for CORS.

To configure the filter, pass a CorsConfigurationSource to its constructor, as shown in the following example:

 @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration() ; config.setAllowCredentials(true) ; config.addAllowedOrigin("http://www.pack.com") ; config.addAllowedHeader("*") ; config.addAllowedMethod("*") ; UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource() ; source.registerCorsConfiguration("/**", config) ; CorsFilter filter = new CorsFilter(source) ; return filter ; }

Of course, you can also use a custom Filter to solve the CORS problem.

 @WebFilter("/*") public class WebCORSFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletResponse response = (HttpServletResponse) res ; HttpServletRequest request = (HttpServletRequest) req ; String origin = request.getHeader("Origin") ; request.setCharacterEncoding("UTF-8") ; response.setHeader("Access-Control-Allow-Origin", origin) ; response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE, PUT") ; response.setHeader("Access-Control-Max-Age", "3600"); response.setHeader("Access-Control-Allow-Credentials", "true") ; response.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Account, access-token") ; chain.doFilter(req, res) ; } }

The above is the full content of this article, I hope it will be helpful to you.