Why do cross-domain and judgment occur?
Cross-domain means that the browser cannot execute scripts from other websites. It is caused by the browser's same-origin (domain name, protocol, port) policy and is a security restriction imposed by the browser on JavaScript.
Cross-domain problems occur when front-end calls are made on different domain names or ports.
So how are cross-domain problems determined? After searching and experimenting came the following steps:
- The browser first matches the front-end page and the back-end interaction address according to the same-origin policy. If the origin is the same, the data request is sent directly; if the origin is different, the cross-domain request is sent.
- After the server resolver receives the browser cross-domain request, it returns the corresponding file header according to its own configuration. If no cross-domain allowed is configured, no field is included in the file header , and +
Access-Control-Allow-originis returned if a domain name is configured .Access-Control-Allow-origin对应配置规则里的域名的方式 - The browser
Access-Control-Allow-originmatches according to the fields in the received http file header. If there is no such field, it means that cross-domain is not allowed; if there is this field, the content of the field is compared with the current domain name. If it is the same source, it means that cross-domain is allowed. domain, the browser sends the request; if the source is different, it means that the domain name cannot be cross-domain, and the request is not sent
Best Practices for Addressing Cross-Domains
The general methods to solve cross-domain include jsonp, CORS (modifying the header header), port forwarding, etc. The first two need to rewrite the server code, and the session will be lost.
A perfect solution is port forwarding. If the first two methods are used, one more port or server ip must be exposed. If only one port of one server can be used for deployment, jsonp and cors will fail.
As shown in the configuration file below, the front-end page is configured on port 8080, the back-end server is configured on port 8000, and Nginx forwards the front-end request prefixed with http://localhost:8080/api/ to http://localhost:8080/api/ :8000
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
server {
listen 8080;
charset utf-8;
location / {
root /home/ivan/Desktop/ProjectManagement/fontEnd;
}
location ~ ^/api/{
proxy_pass http://localhost:8000;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;
}
}
|
So, at present, nginx is still the best time to deploy front-end and back-end servers. In the development environment, the front end can use http-proxy-middleware to solve cross-domain problems.
server {
listen 80;
server_name your.domain.name;
location / {
proxy_pass http://localhost:5000/; # Forward the request under the root path to the development server opened by the front-end toolchain (such as gulp). If it is a production environment, configure it as a static file server using instructions such as root
}
location /api/ {
proxy_pass http://localhost:8080/service/; # Forward requests under the /api path to the real backend server
proxy_set_header Host $http_host; # Pass the host header, the backend service program will receive your.domain.name, otherwise it will receive localhost:8080
proxy_cookie_path /api /service; # Replace the path part in the cookie from /api to /service
proxy_cookie_domain localhost:8080 your.domain.name; # Replace the path part of the cookie from localhost:8080 to your.domain.name
}
}