I don't understand why everyone is so hard to explain the "cross-domain restriction" thing? ! A bunch of academic terms are given out at every turn, such as Shenma's "same-origin policy" and "restricted loading" blabla... When it comes up, it is explained in highly abstract words. Beginners may only say one sentence: please speak human words.
"Cross-domain" is a restriction made on the browser. According to the client-server model, some restrictions are made on the client side. If we don't consider cross-domain first, then, assuming that clicking a button on the page involves a data request that needs to be requested from a third-party website, what solutions do we have?
- The most intuitive idea is that since you need to access the information of the third-party, then I just send an asynchronous request (Ajax) directly from the browser (that is, the client side).
- A slightly more devious method is: I send the information of the third-party that needs to be requested to my server, and let the server send the request for the third-party. After the server gets the returned data, it sends it back to the client.
Obviously, the first method is much more intuitive, and the second method feels like unnecessary effort. Especially the back-end students will agree with this opinion: what data do you need in the front-end, you can just call and access it yourself, why not give it to me for access? I'll send it back to you when I get it, are you so lazy? !
The so-called "cross-domain restriction" means that the browser directly prohibits the first solution. It is a mandatory requirement that any data request for the third-party must be sent back to its own server, allowing you to The server side does processing, and then returns the information to the client side.
(How to judge whether it is a third-party request?! Very simple, your website itself has a domain name, and your domain name is tied to your own server ip. Any request that does not start with your own domain name will be It is considered as a third-party request. The so-called "same origin" refers to "the same request source as your own, that is, the same domain name".)
As mentioned above, who made this "prohibition"? Only refers to the browser. And what if the client is a mobile app? Or what about a desktop app? Of course, it is not limited by this method, because such native apps are not controlled by the browser, so third-party requests can be sent directly on the client side. Of course, the students at the back end will happily tell the students on the App side, please send the request yourself, and don't come to me.
So why do browsers have to do such weird restrictions? The answer, of course, is for the safety of the entire web ecosystem! One of the most intuitive ways to do evil is, if your js code on the browser side can access third-party data arbitrarily, then you can let your js code regularly poll the access to this third-party, such as accessing every second once. Then, any user who is browsing your webpage will visit this third-party website at a frequency of one request per second. Assuming that 100,000 people are browsing your webpage, then this third-party website has to bear 100,000 invalid visits per second. Who can bear this. . . Of course, what is being said here is that you do evil to others. But if you let go of the same-origin policy, everyone is equal, and others can use the same method to do evil to your website. In this way, the entire web ecosystem will be flooded with such a large number of invalid requests that no one can access web pages normally, because the bandwidth is eaten up by invalid requests.
Therefore, even if only considering this evil method, the first intuitive and convenient method of requesting third-party information should be banned. Of course, you might say, so, can the App side of the mobile phone/desktop do the same evil? ! Hmmm, you may have forgotten that App needs to review this matter.