Shulou(Shulou.com)06/03 Report--

This article focuses on "how to deal with errors in cross-domain requests". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to handle errors in cross-domain requests".

Cross-domain request

If you haven't encountered it, try typing the following code on the console page of your browser:

Const xhr = new XMLHttpRequest () xhr.onreadystatechange = () = > {if (xhr.readyState = 4) {console.log (xhr.status = 200? Xhr.responseText: 'error')}} xhr.open (' GET', 'https://google.com') xhr.send ()

This code makes a request to Google by calling the browser's XMLHttpRequest, and the result is as shown in the figure:

This is the problem of cross-domain requests. When requests are sent to different sources through JavaScript, the response to the request will be intercepted by the browser and not handed over to JavaScript for processing. The "different source" here means that the target resource is different from the domain (domain), communication protocol (protocol) or network port (port) of the current web page as long as there is any difference. For example, here are a few examples:

Suppose the current user is in: https://example.com: [✅] https://example.com/test-> same domain [❌] https://m.example.com-> different domain [❌] https://example.com:3000-> different port [❌] http://example.com-> different communication protocols

Understand what cross-domain is, so why do browsers intercept cross-domain request resources?

In fact, this is taking into account the user's information security.

Suppose Xiaohei is a malicious developer, the website he wrote will try to call Baidu, Weibo and other target websites through XHR; if the user already has the login status of the target website, Xiaohei can pry into his privacy and get data that should not be obtained. Come to think of it, if the target sites are replaced by Email, banks, and e-commerce, malicious developers can do whatever they want without browsers restricting the protection of cross-domain requests.

Note: although cross-domain requests are intercepted by browsers, they are intercepted by Response rather than Request.

Solution

There are many solutions for cross-domain requests, such as JSONP, that is, through tags in HTML with no cross-domain restrictions, such as img, script, etc., and then interfacing the content of the response back to JavaScript by specifying a callback function, or through iframe to obtain target resources by bypassing cross-domain protection. Here are only two common and relatively formal solutions.

1. CORS

The most standard and correct solution is through the W3C specification of "cross-domain resource sharing (Cross-Origin Resource Sharing, CORS)". Through the setting of the server in the HTTP header, browsers can obtain resources from different sources.

In the CORS specification, the operation of cross-domain access control is clearly defined.

First of all, the server needs to add settings such as Access-Control-Allow-Origin, Access-Control-Request-Method, Access-Control-Request-Headers to the response header to limit the source that the server can accept, the method of request, the header that can be carried, and so on.

When the browser sends a resource request, it will send the request directly if it is a simple request; if the above conditions are not met, it will knock on the door through the Preflighted request to confirm whether it can pass the restrictions of the server before sending the formal request.

In addition to the above contents, CORS also has information about the transmission mode of Cookies, how to allow cross-domain writing to Cookies, and so on.

two。 Proxy server

Since the CORS header setting is on the server side, if the server is your own, you can easily adjust the server settings so that the front end can get the necessary resources; but if you request an external API, you can't ask someone else to modify the header setting every time you encounter a CORS error.

The simple method of violence is to help us obtain resources through a proxy server; since the limitation of cross-domain protection is the specification of the browser, there will be no restrictions as long as the request is not sent through the browser.

A common practice is to do a simple reverse proxy through nginx. For example, in your own development environment, where the front and rear ends are separated from each other, and the front and back end services are started on ports 3000 and 5000 respectively, you can use this configuration:

Server {listen 3000; server_name localhost; location ^ ~ / api {proxy_pass http://localhost:5000;}}

When the current end needs to send an API request, it can directly request localhost:3000/api/...,. The request will be intercepted by nginx and forwarded to the localhost:5000 where the backend is located, so that cross-domain protection can be easily bypassed.

At this point, I believe you have a deeper understanding of "how to handle errors in cross-domain requests". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.