Cross-domain problems with front – and back-end separated projects are unavoidable. In general, the front-end is written by frameworks such as React and Vue, and the server API is requested through Ajax, and the data is transmitted in JSON format.
So why is there a cross-domain problem? What are the ways to solve cross-domain problems? So to understand these two problems we need to understand what the same origin policy is.
The same origin policy of the browser
The Same Origin policy is a security convention that is one of the core and most basic security features of all major browsers. The same origin policy stipulates that client scripts in different domains cannot request resources from each other without explicit authorization. Same-origin indicates that the domain name, protocol, and port are the same.
For example, if we visit a website, the page requests the following address:
In addition, the same origin policy is classified into the following two situations:
- DOM same-origin policy: Operations on the DOM of pages from different sources are prohibited to prevent IFrames. For example, iframe tag put a Alipay payment page, if there is no same-origin policy, then the phishing site in addition to the domain name is different, the other can be exactly the same as alipay’s site.
- XMLHttpRequest Same-origin policy: Disables the use of XHR objects to make HTTP requests to servers of different sources. For example, the website records the bank’s cookie. When you visit a malicious website, the hacker gets your cookie and requests the previous bank website through Ajax, so he can easily get your bank information.
Therefore, because of the same origin policy, everyone’s network environment is relatively safer.
Solutions to cross-domain problems
Knowing the same origin policy, you can see why cross-domain problems arise. It’s all about security. But in practice, people still need to access resources across domains. A typical application scenario is a project where the front and back ends are separated. So how do we solve cross-domain problems?
CORS- Cross-domain resource sharing
CORS is a W3C standard that defines how clients and servers communicate to resolve cross-domain problems when they arise. In fact, the convention is to define some custom HTTP headers so that the server can identify the request as passing or failing when the client initiates the request.
Browsers classify CORS requests as simple and non-simple:
A simple request
A simple request must meet the following two conditions:
- The request mode must be HEAD, GET, or POST.
- The Http request header must only be: Accept, accept-lanuage, content-lanuage, last-event-id, content-Type, Content-type is limited to application/ X-www-form-urlencoded, multipart/form-data, text/plain.
Non-simple request
A non-simple request is one that does not meet the simple request criteria. For non-simple requests, the browser will initiate a precheck request. Precheck request means that when the browser detects that your page contains cross-domain requests, it will send an OPTIONS request to the corresponding server to check whether the server will allow cross-domain requests for the current domain name. If the server allows the domain name request, the server returns the 204 or 200 status code. When the browser receives the permit request, it sends the corresponding GET, POST, PUT, or DELETE request. At the same time, the server also informs the browser how long the precheck request is cached. Within this period, the browser will not initiate the precheck request again.
The principle is basically the above mentioned, how can we solve cross-domain problems through configuration in real business? Basically, there are three common ways:
Nginx configuration
In general, we can solve the cross-domain problem by adding the following configuration to nginx:
Nginx is the most comfortable way to do this, without requiring the client and server to do more work, no code intrusion.
jsonp
Because script tags are not affected by the browser’s same origin policy, they allow cross-domain requests for resources (each of our pages references a large number of third-party JS files). So you can use dynamic script tags to make cross-domain requests via SRC attributes, which is how JSONP works. But JSONP only supports GET requests, so this is not a good approach.
Server-side code control
Cross-domain request support can be added on the server side:
This approach acts as a global filter, filtering all requests once.
However, nginx configuration and server Control cannot exist at the same time. Otherwise, the “Access-Control-allow-origin Not Allow Multiple value” error will be reported. I personally recommend nginx configuration once and for all, without requiring every Web project to write cross-domain code.
Have you ever encountered cross-domain problems in your work? How are they solved? Welcome to the comments section to exchange discussion and learn together ~
At the end
This issue is to share here, I am xiaobian South wind blowing, focus on sharing interesting, novel, practical open source projects and developer tools, learning resources! I hope to learn and communicate with you together. Welcome to follow my official account ** [Github navigation station] **.
Phase to recommend
It’s beautiful! With three open source icon libraries, you don’t have to ask designers anymore
10 unique vue.js libraries! Good use, twice the result with half the effort!
Just in time! 13 Spring Boot training programs, use it well, promotion and salary will not worry
The programmer connects the private life necessary background frame, need not repeat to build the wheel, net friend: too easy to use!
Still working on the project from start to finish? Use these six SpringBoot projects well, get twice the result with half the effort!
Middle-aged netizens can finally understand young people’s AWSL