I’m participating in nuggets Creators Camp # 4, click here to learn more and learn together!

This article is an original article, please quote the source, welcome everyone to collect and share 💐💐

background

Cross-domain issues facing development environments

We usewebpackorviteWhen developing local projects, the browser will typically enter the domain name:127.0.0.1:3000To debug the page. When requesting a three-party interface “take any API for example”, the following happens…The target server blocks your request because they have a gateway protection policy, which is called request cross domain.

But in test and online environments it doesn’t exist becausehttps://api.juejin.cnThe gateway interception layer of the server whitelisted both environments, so no cross-domain error occurred.

So the problem comes, we also want to call https://api.juejin.cn interface to get data, how to do? There are several methods:

  1. lethttps://api.juejin.cnfor127.0.0.1:3000Develop a whitelist;
  2. Use mock platforms or create fake data locally;
  3. Through gateway proxy;

Plan 1 is the simplest but most dangerous. Once the remote service to the local open whitelist, equivalent to others can attack your server in the local, service vulnerability is good, once the service intrusion to give you a deletion database run is not cool.

Scheme 2 also has disadvantages, mainly embodied in code intrusion and code recovery. Whether to call the mock platform can be identified according to the environment variable, but it also needs to wait for the backend students to hang up the API mock platform and adapt, which will undoubtedly increase others’ work. Local fake data is not said, code intrusion is not only strong, when the data structure is complex, but also linked to multiple modifications, if these changes are not restored before the online, then wait for operation and maintenance to call you to deal with online bugs.

Scheme by three resources | request intercept, the 127.0.0.1:3000 / API/XXX request path forward to https://api.juejin.cn/api/xxx, and cancel cross-domain limitation, finally get the remote data.

To sum up: Scheme 3 is relatively small both in terms of heavy code intrusion and development dependence, and it is also the mainstream debugging method at present. It will be described in detail below.

Common proxy scheme

Switch to native proxy or use third-party proxy software to block requests

Need more additional learning costs and environment construction, abandoned;

Vite provides built-in proxy support

To configure proxy in vite.config.ts: redirect 127.0.0.1:3000 to the target domain name, skip the cross-domain restriction with server capabilities:

This allows you to forward the API for 127.0.0.1:3000/example1 to https://xxx.com/example1 and ignore the cross-domain restrictions.

However, there are some downsides to this: since you are accessing the URL 127.0.0.1:3000, any third-party requests (such as the 302 login redirect returned by the third-party authentication service, cross-service cooperation API, etc.) will need to be configured here, and the following might look like this…

There are exaggerations, of course, but they also reflect the fact that the tripartite business is an unpredictable black box, and you don’t know how many constraints there are associated with it, so you shouldn’t “add” but “subtract” on the agency side.

Whistle agent"Recommended"

Whistle is a powerful tool like Fiddler and Charles that you can find out more about here.

Take a look at the basic whistle agent configuration:

ResCors ://enable means to ignore cross-domain restrictions./ / baidu.com / / 127.0.0.1:3000 resCors: / /enable
Copy the code

So when you visit Baidu.com, the browser will come up with 127.0.0.1:3000 content. Now that we know the basics, let’s talk about how to use whistle to “subtract” and make it work once and for all.

Whistle Proxy configuration

1. Install the whistle

npm install -g whistle
Copy the code

2. Start the whistle

# start
sudo w2 start

# close
sudo w2 stop
Copy the code

3. Install the plug-in

Install the Chrome Proxy plug-in Proxy SwitchyOmega, which is a Proxy selector, without a local network to achieve a quick switch between different proxies.

4. Configure Proxy SwitchyOmega

Add your Whistle Proxy service to Proxy SwitchyOmega.

Click “Options” in the plug-in and refer to the following configuration:

5. Whistle Rules configuration

Open the Whistle page 127.0.0.1:8899, create a new rules on the left, paste the content of the project SRC /.whistle (see rules configuration below) and save it.

6. Enable the proxy switch

The Proxy SwitchyOmega plugin selects the Proxy you want to specify “step 4 screenshot is” whistle “and then accesses a remote URL (such as my.com).

Use opportunely whistle

Whistle Rules configuration

If your project remote domain name is my.com, the rules configuration is as follows:

# SRC /.whistle
# whistle configuration, paste everything into the rules of Whistle
# add environment variables as needed
//my.com jsPrepend://{paas.js}

# Turn off cross-domain restrictions
* resCors://enable

# set related address to local, other remote^ my.com $/ / 127.0.0.1:3000 resCors: / /enable/ / my.com/%23/ / / 127.0.0.1:3000 / % 23 / resCors: / /enable/ / my.com/node_modules/ / / 127.0.0.1:3000 / node_modules/resCors: / /enable/ / my.com/src/ / / 127.0.0.1:3000 / SRC/resCors: / /enable/ / my.com/@vite/ / / 127.0.0.1:3000 / @ vite/resCors: / /enable/ / my.com/@id/ / / 127.0.0.1:3000 / @ id/resCors: / /enable
Copy the code

Line by line:

My.woa.com jsPrepend://{paas.js} : If you specify a mock file, command + will automatically create a paas.js file for you. Just write your JS code in the file. My.com will execute your logic first. The goal is to enhance the framework’s ability to mock and construct local environments flexibly.

Line 5 * resCors://enable: Disables all cross-domain restrictions. By doing this, no matter how many tripartite business black boxes your project has, it is not subject to cross-domain restrictions, which is a key step in “subtraction”.

Line 8 to 13: specify the relevant address to go local, other remote, including: Document, routing page, vite development environment resource loading fixed list, etc. This allows all requests to go remote after subtracting the specified resource.

Vite tool library Settings

If you configure whistle but not Vite, the access page is constantly refreshed. (Github Issue: Vite always Refresh and connecting)

To solve this problem, you need to configure the HMR policy in vite.config.js, which only involves 127.0.0.1 host resources to start HMR:

export default defineConfig(({ command, mode }: ConfigEnv) = > {
  return {
    / /... Other configuration
    
    server: {
      hmr: {
        protocol: 'ws'.host: '127.0.0.1'}}}; });Copy the code

So far, as long as the local project started, after entering my.com in the browser, the page load is your local project, and involving three-party requests, can also bypass the cross-domain restrictions, to achieve remote environment simulation.

Effect comparison of agent schemes

Take a look at the framework flow chart above that describes the two proxy schemes:

  • Vite proxy scheme: on the basis of the local server, constantly add cross-domain proxy, with the increase of docking services, front-end development environment presents a snowball configuration overlay, is not a good way;
  • Whistle agent: start all proxy can cross domain by default, as long as the proxy of resources | don’t walk path exclude out, accord with “subtraction” rules of computer engineering.

Write in the last

Unfortunately, I don’t have a separate Git project for this project, and the project is not complex enough to be a separate project. If you have any questions or suggestions, please feel free to post them in the comments section, respect!! 💐 💐