CORS

The basic idea of CORS is to let the browser and server communicate through the request header to determine whether the request will succeed

In some cases we will have a precheck request before sending a formal request, which is sent using the options request method to get the format of the request header allowed by the server, involving the following headers:

Origin

Where does the cross-domain request come from

Access-Control-Request-Method

What methods can be used to indicate the request GET, POST, PUT…

Access-Control-Request-Headers

Headers that may be used when requesting

The response header basically corresponds to the request header, including:

Access-Control-Allow-Origin

Indicates the original address of the cross-domain request received by the server. Cross-domain is not allowed if the origin of the request header does not match the field set. * indicates that any request is accessible

Access-Control-Allow-Credentials

Indicates whether the request should carry a cookie. If it is set to false but the browser passes a cookie, the browser calls the onError event handler. In the case of fetch request, the value is set to include, indicating that authentication information such as cookies and HTTP Basic authentication in the local resource domain of the request is always sent regardless of whether the request is cross-domain.

Access-Control-Allow-Headers

Indicates what headers are supported across domains

Another Access – Control – Allow – the Methods | Access – Control – Max – Age respectively, such as cross domain support method and the time in the process of the request can be cached

Nginx

Through reverse proxy, the request address and the server are co-domain, so that the front-end is not cross-domain.

The comparison

1. Front-end configuration

Cors: To carry cookies we need to set withCredentials to true

Nginx reverse proxy: In this case, the front end does not cross domains and is consistent with normal requests. No additional configuration is required

2. Back-end configuration

Cors: Sets the a-C-A series of headers, for example:

'Access-Control-Allow-Origin' The '*';
'Access-Control-Allow-Credentials' "true"; 
'Access-Control-Allow-Headers' 'X-Requested-With';
Copy the code

Nginx reverse proxy: No cross-domain configuration is required on the backend

3. Configure the server

Cors: no

Nginx reverse proxy: This solution focuses on server configuration, for example

.proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Real-Port $remote_port;
proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for; .location /api {
   proxy_pass https://b.test.com; Set the protocol and address of the proxy server
   proxy_cookie_domain b.test.com  a.test.com; Write cookies to request and response}...Copy the code

4. Security

Cors: In this case, the browser adds the origin attribute by default. The server can query the request source, control the source, and block blacklisted links. At the same time, the domain name and port of the server are exposed

Nginx: There is no default origin header in the reverse proxy solution, but the x-forward-for header can be used to view client and proxy IP addresses at all levels, thus achieving a certain degree of backtracking and blacklist masking. In the reverse proxy, you can access the interface server using an Intranet address, which protects the interface server from exposure to some extent.

5. Portability and expansibility

Cors: you just need to configure corresponding head, scalability is not much said, need to add a layer of limiting condition, don’t need to cancel, limiting portability for yourself you can understand not cross domain, and then from an online blog search once and then copy it can be used without any modification, I believe you know 😎 portability is good

Nginx: The location of the proxy can be changed according to the domain name of the server. In addition, the proxy server port is occupied and other changes need to be made according to the service environment. In addition, complex configuration will undoubtedly increase the maintenance cost in the later period.

server { 
    listen       8443;
    server_name  a.test.com;    
    client_max_body_size            100m;
        
    ssl. location /micro{proxy_pass   https://b.test.com;  # Reverse proxy
        proxy_cookie_domain b.test.com a.test.com; # modified cookies
        add_header 'Access-Control-Allow-Origin' 'htps://c.test.com';
        add_header 'Access-Control-Allow-Credentials' "true"; 
        add_headerAccess-Control-Allow-Headers X-Requested-With; }}Copy the code

The proxy model above is a.test.com reverse proxy to B.test.com,

Then c.test.com cors to A.test.com and reverse proxy to B.test.com

conclusion

	CORS	nginx
The front end	withCredential = true
The back-end	A-C-A headers
The server		Nginx configuration
portability	Ok, no extra configuration required	Slightly worse, according to different environment to carry out the corresponding configuration
security	Controlled source, direct trace	Trace multi-level sources through x-forward-for
scalability	Whitelist control	Updating the configuration cross-domain model results in changes

reference

A simple comparison between CORS cross-domain and Nginx reverse proxy cross-domain advantages and disadvantages