An example of a method for configuring cross domain failure fixes for nginx

  • 2020-05-24 06:46:44
  • OfStack

The nginx configuration does not take effect across domains as follows


server {
  listen  80;
  server_name localhost;
  
  #  Interface forward 
  location /api/ {
   #  Allows request addresses to cross domains  *  As a wildcard 
   add_header 'Access-Control-Allow-Origin' '*';
   #  Sets the request method across domains 
   add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
   #  Set whether to allow  cookie  transmission 
   add_header 'Access-Control-Allow-Credentials' 'true';
   #  Set request header   Why don't you set wildcards here  *  Because they don't support 
   add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X-Requested-With,X-Data-Type,X-Auth-Token';
   #  Set up the reverse proxy  
   proxy_pass 127.0.0.1:8081/;
  }
 }

The nginx cross-domain configuration on the Internet is mainly the above version, however, many are copied 1 copy, and not really to practice, so I wrote an article to remind people in need, do not blindly copy, learn to analyze.

nginx takes effect after modifying the following configuration


server {
  listen  80;
  server_name localhost;
  
  #  Interface forward 
  location /api/ {
   #  Allows request addresses to cross domains  *  As a wildcard 
   add_header 'Access-Control-Allow-Origin' '*';
   #  Sets the request method across domains 
   add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
   #  Set whether to allow  cookie  transmission 
   add_header 'Access-Control-Allow-Credentials' 'true';
   #  Set request header   Why don't you set wildcards here  *  Because they don't support 
   add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X-Requested-With,X-Data-Type,X-Auth-Token';
   
   #  Set up the  options  The request processing 
   if ( $request_method = 'OPTIONS' ) { 
    return 200;
   }
   #  Set up the reverse proxy  
   proxy_pass 127.0.0.1:8081/;
  }
 }

The main difference between the two is the following line of code


if ( $request_method = 'OPTIONS' ) { 
  return 200;
}

Because the post request browser will send a pre-check request of options, it will mainly send the request header to the server, and if the server allows, it will send the real post request, so f12 sees that post often sends two requests. Because the back-end java code does not process the options request, when the options interface request is made, it reports 403 forbidden. Here, the request of nginx to options is directly returned to 200. Without reaching the interface layer, the post response header is directly allowed

A bonus tip

proxy_pass 127.0.0.1:8081/;

For this/add or not problem in reverse proxy;

Visit http: / / localhost api/user/login;

Add/actual access is 127.0.0.1:8081 / user/login; Do not add/actual access is 127.0.0.1:8081 / api/user/login;

The use of slashes means that all /api requests will be forwarded to the root directory, which means /api will be/replaced, which means the interface path will be changed and one layer /api will be missing. What about when you don't have slashes? This means that the /api path will not be lost when forwarding to the domain name 127.0.0.1:8081


Related articles: