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