preface

In ordinary work, front-end debugging interface cross-domain issues, in fact, is a big thing. In particular, when a server returns data from the back end temporarily unable to adjust the response header caused by cross-domain problems, I would like to share with you some cross-domain debugging methods.

concept

Before addressing the problem, talk about the cause of the problem (skip this paragraph if you have a foundation). Front-end security considerations, do not send requests to other pages without authorization, otherwise it will lead to serious security problems, such as calling another website interface to transfer money away, this is a very dangerous thing! Based on this, it is not uncommon to see some of your requests blocked. So what is cross-domain?

type value
agreement http/https
The host name juejin.im
The port number 80

If only one of the three is different, it can be considered cross-domain.

Summary of general debugging methods for cross-domain projects

Jsonp, nginx proxy, Webpack proxy, NodeJS express and so on, these have been said enough, I share some of my own simple operations, I think more simple and rough effect fast.

Use chrome launch parameters

  • Using Chrome launch parameters is the easiest and fastest way to turn off cross-domain restrictions. First of all, for the sake of safety (it is seriously recommended not to open it to browse the web and other daily, there are security risks!) In the upper right corner of Chrome, create a new test user and a shortcut will appear on the desktop. With this shortcut, change its target in the properties:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="c:/MyChromeDevUserData"
Copy the code

As you can see, I’ve added two parameters. The first one is disable-web-security, which is the key to turning off cross-domain, and then I usually set up a user directory to hold the data generated by Chrome. Then open the link and you’ll find a brand new cross-domain browser. It can also load local files. In the meantime, think again. Chrome is a crawler.

Use chrome development tools

First open the F12 developer tools and go to Sources>>Overrides.

This is a resource broker tool for Google Developer Tools, which can be used to broker content to local files, such as images, GET, POST requests, etc. To make it easier, we create a new JSON file locally, which can be read directly and proxy our GET and POST requests.

Simulate the request interface. If the interface has parameters, replace the question mark with %3f as the file name. Such as https://www.baidu.com/sugrec?prod=pc_his, the file name should be sugrec % 3 fprod = pc_his note on www.baidu.com directory. Re-initiate the request and discover that the page content has been proxied locally.

Post requests can also be propped, but note that, for example, http://xxx.cn/xxx/ can be propped to an HTML file as xxx.cn/xxx/index.html. Post is sometimes the root path, so you need to work around this slightly.

Use the Chrome plugin

The Google plugin gives you powerful cross-domain permissions (and if you log in, it carries status), and we can make a very simple demo plugin with this amazing feature. You can even rewrite requests, cookies, and so on. Agency is not to mention. The background.html running behind the Google plugin can be cross-domain, and we can use the message passing of the plugin to complete the usual cross-domain request. For the explanation of the plug-in here, you can move to the plug-in boss’s article: [dry goods] Chrome plug-in (extension) development overview.