With Nginx proxy requests, the front and rear side cross-domain processing

　　Since the front-end spa frame appears, the front and rear ends are separated developed. We will inevitably encounter problems in the development of cross-domain. Cross-domain method to solve this problem are basically server side implementation. To java, for example, I know that there are three ways to deal with cross-domain:

　　1. Use @CrossOrigin 注解对每一个接口进行跨域处理,缺点是比较麻烦

@CrossOrigin(origins ="*")
@RequestMapping(value = "/test", method = RequestMethod.GET)
public String test() {
    return "test";
}

　　2. @CrossOrigin cross-domain processing of all interfaces in the inlet class

@CrossOrigin(origins = "*")
@RestController
@SpringBootApplication
public class SpringBootCorsTestApplication {
    // ***
}

　　3. The configuration may be added to a class, the processing of all cross-domain interfaces

@Configuration
public class WebMvcConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("*")
                .allowedMethods("POST", "GET", "PUT", "OPTIONS", "DELETE")
                .maxAge(3600)
                .allowCredentials(true);
    }
}

　　But ... the back end of our project team they do not deal with cross-domain code, unified configuration cross-domain process by nginx line ... we use the front end of vue, vue configuration is for the development of cross-domain process, due to the the special nature of our project, not for us (we will deploy a set of code to run on different servers, at least three sets of front and rear side code are different, we solve the agency managing the branch by gitlab, we pulled out the differences become different configured version of the code, such as a different background api interface address, we just started building when the front-end code will be configured to play in, or find this code and configuration silly could not tell, this sub-process is not very good, we have to front-end complete separation of code and configuration, code and configuration are established two gitlab warehouse, when the front end of the project to build the only building code, configuration will be replaced by a script for a particular environment at deployment time, I feel like a monkey with a patch somewhat similar to this is achieved with the same set of back-end java code read different configurations with different commands run run ) In the nignx own understanding of bulk configuration, you can make a request through the local proxy forwards nginx, and nginx in handling cross-domain in

server {
    listen 9090;
    server_name localhost;

    location /{
        add_header 'Access-Control-Allow-Origin' $http_origin;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' '*';


        if ($request_method = "OPTIONS") {
            add_header 'Access-Control-Allow-Origin' $http_origin;
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
            add_header 'Access-Control-Allow-Headers' '*';
            add_header 'Content-Length' 0;
            add_header 'Content-Type' 'text/plain, charset=utf-8';
            return 204;
        }

        proxy_pass http://192.168.0.3:9999;
    }
    
    #location /aepreservation {
    #
    #    add_header 'Access-Control-Allow-Origin' $http_origin;
    #    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    #    add_header 'Access-Control-Allow-Headers' '*';

    #    if ($request_method = "OPTIONS") {
    #        add_header 'Access-Control-Allow-Origin' $http_origin;
    #        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    #        add_header 'Access-Control-Allow-Headers' '*';
    #        add_header 'Content-Length' 0;
    #        add_header 'Content-Type' 'text/plain, charset=utf-8';
    #        return 204;
    #    }
    
    #   proxy_http_version 1.1;
    #   proxy_set_header Upgrade $http_upgrade;
    #   proxy_set_header Connection "upgrade";
    #    proxy_pass http://192.168.0.3:9999;
   #}
}

　　nginx monitor all ports of local port 9090 and forwarded to the corresponding back-end services (if the address of your back-office services for http://192.168.0.3:9999/api/*, as long as our front-end proxy access http: localhost: 9090 / api / * on it, pay attention to the bottom of my comments places is a method of proxy websocket, the path is / aepreservation, I was to lazy (regular looking at a headache), copy a top configuration, ningx is then judged by a positive the only path to determine websocket be processed, as I do not have to write such a long-winded