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

Sorry about that… Please hit me with your resume… Ant Financial – Sesame Credit recruitment front P6/7, JD reference position, limited quota, come quickly ah…

I’ve written a few posts about the fundamentals and common misconceptions of cross-domain correlation solutions after a back-end separation project, including CORS and Nginx reverse proxies. In these two projects are in use, each have their advantages, about the specific use which kinds of schemes, everyone’s ideas are not consistent, this article mainly begins, from the front end and the server configuration flexibility, scalability, security, transplantation, etc, the detailed contrast two scheme is superior to domestication, in order to later on scheme selection to be of help.

First, front-end configuration

CORS solution: Some browsers do not carry cookies by default in cross-domain scenarios. Therefore, to carry cookies, you need to set the withCrendetails property of XMLHttprequest. The Settings are as follows when vue-resouce is used

Vue.http.options.credentials = true
Copy the code

With Axios, you can set the following in the interceptor

axios.interceptors.request.use((config) = > {
    config.withCredentials = true
    return config
}, (error) => {
    return Promise.reject(error)
})
Copy the code

With the native XMLHttpRequest object,

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
Copy the code

If you do not need to pass cookies, set this parameter to false to avoid situations where different browsers allow cookie portability by default.

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 solution: For simple requests the back end needs to wrap the ACA series headers,

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

For complex cross-domain requests, a one-step pre-check process needs to be handled.

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

3. Server configuration

CORS solution: None. Nginx reverse proxy: This solution works on the Nginx server across domains and is configured as follows

. proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Real-Port $remote_port; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; . location /api { proxy_pass https://b.test.com; Proxy_cookie_domain b.test.com a.test.com; Request and Response cookies are written to each other.Copy the code

The principle can be seen in the previous two articles

Four, security

In the CORS solution, the browser adds the origin attribute by default. In this case, the server can directly query the source of the request, which facilitates the control of the source and the blocking of blacklisted links. The server domain name and port are also exposed. Nginx Reverse proxy: The reverse proxy solution does not have the default Origin header to use, but you can use the X-forward-for header to check the client and proxy IP addresses at all levels, and to achieve 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. Flexibility and expansibility of migration

CORS solution: you only need to configure the blacklist and whitelist in the code or configuration center, which is convenient for transplantation and expansion. Nginx reverse proxy: Different environment service domain names may be different, so Nginx configuration is different, which is not easy to transplant. For extensibility, when a new project needs to access the interface server, it needs to access the domain name specified by the server in nginx first, and then the server domain name is reverse-proxy to the interface server, for example

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

At this point, the cross-domain model changes from pure A.test.com reverse proxy to B.test.com, to a.test.com reverse proxy to B.test.com and c.test.comCORS to A.test.com and then reverse proxy to B.test.com. This is a little tricky, but if you think about it, it makes sense. This undoubtedly increases the later maintenance cost.

Comprehensive comparison

Based on the above, we can get the following roughly

Contrast the conclusion

To sum up, for public basic services, as there may be more front-end projects involved in docking, as well as more development, test and deployment environments, I tend to recommend the USE of CORS scheme. For small projects with strong antagonistic features, nginx can reduce your development costs and get you up and running quickly. Specific use also should combine the job actual of course, use according to need. In addition, when using the Nginx reverse proxy scheme, it is recommended to use the internal domain name/IP address as the entrance of the interface server. Do not expose the internal domain name/IP address to avoid unnecessary security problems.

Emmm recently we are still hiring, Ant Financial – Sesame credit recruitment front P6/7! Rare opportunity! Come on! You can do it! Big factory you understand, bonus points you half ah, interested in quick to try it, interested in wechat chat plus MY ha Heiohiio, resume directly throw my mailbox can also be ~ [email protected]

Welcome to discuss with us