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

This article introduces how to deal with cross-domain problems in Vue. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Not cross-domain cross-domain

If you introduce Vue directly into the project and use Vue like jQuery, that's no problem, and you shouldn't have cross-domain questions. But if you are doing a single page application (SPA), then there is bound to be such a question, how to do cross-domain problems!

Because in a single-page application, the front-end project can be launched separately through node, it occupies a separate port, and the back-end project is also another port after startup. At this time, the request is sent from the front-end to the backend. Because the two are on different ports, there must be a cross-domain problem.

But if you think about it, this cross-domain may only exist in the development environment, but may not exist in the production environment. Because when the project development is completed, we can package the front-end project, deploy it on Nginx or copy it directly to the back-end project to run (the former is generally used):

If it is the former, and the back-end interface is also mapped through Nginx, there will be no cross-domain problem at this time. If it is the latter, it will be even easier. When deploying, the front and back end codes are put together, let alone cross-domain problems.

Therefore, to solve this so-called "cross-domain" problem, we can not follow the traditional way of thinking (through JSONP or CORS), because after the project is actually online, the so-called cross-domain problem may disappear.

So how to solve this problem? We can configure request forwarding in the front-end nodejs.

It's not difficult to configure request forwarding, but vue-cli2 and vue-cli3 are written in a slightly different way, which is where I stepped on it some time ago.

Vue-cli2 scheme

If we use the vue-cli2 to create the SPA application, after the creation is successful, there is an index.js file in the project's config directory, in which we can configure request forwarding, as shown below:

The configuration is as follows:

Module.exports = {

Dev: {

/ / Paths

AssetsSubDirectory: 'static'

AssetsPublicPath:'/

ProxyTable: {

'/': {

Target: 'http://localhost:8082',

ChangeOrigin: true

PathRewrite: {

'^ /':'

}

}

'/ ws/*': {

Target: 'ws://127.0.0.1:8082'

Ws: true

}

}

...

}

ProxyTable is the forwarding routing table we configured. We have configured a total of two rules in this:

The first is to intercept all HTTP requests and forward them to the back-end server (the front-end default port is 8080), and the back-end port is 8082. As for the interception rule /, you can customize it and write it according to the actual situation. For example, all HTTP requests have a uniform prefix api, so you can write / api here. The second is to intercept all websocket requests for forwarding. I have a uniform prefix / ws for all websocket requests here.

If you have more interception rules, you can continue to configure them here. These configurations will only take effect in the development environment. When the project is compiled and packaged, these configurations will not be packaged. That is to say, when the project is released, these configurations will be invalid. At this time, we will use Nginx or copy the front-end code to the backend. The cross-domain problem in the production environment can be solved ("equivalent to the cross-domain at development time does not exist in the production environment").

Relatively speaking, vue-cli2 is relatively easy to configure here.

Vue-cli3 scheme

After vue-cli3 came out last year, he tasted a handful of fresh food at that time, but maybe vue-cli2 has been used for a long time, so he won't accept vue-cli3 for a while, so he put it down after tasting it and didn't use it much. Until the other day, the new project tried vue-cli3 and fell into the hole when the request was forwarded.

I didn't think much about it at first, but it is still the old method in vue-cli2, but it is configured in the vue.config.js file of the project created by vue-cli3, as shown below:

Note that the SPA application created with vue-cli3 has no config directory, so we will configure the request forwarding configuration in the vue.config.js configuration file.

At first, I copied the request forwarding configuration in vue-cli2 directly, so it's okay to send HTTP requests, but there has always been a problem with websocket requests. Later, after careful analysis, I found that there is a slight difference in request forwarding configuration between the two. Let's take a look at the request forwarding configuration in vue-cli3 (this is also the complete content of my vue.config.js file here).

Let proxyObj = {}

ProxyObj ['/ ws'] = {

Ws: true

Target: "ws://localhost:8081"

}

ProxyObj ['/'] = {

Ws: false

Target: "http://localhost:8081",

ChangeOrigin: true

PathRewrite: {

'^ /':'

}

}

Module.exports = {

DevServer: {

Host: 'localhost'

Port: 8080

Proxy: proxyObj

}

}

First of all, we create a proxyObj to put all kinds of proxy objects, and the content of the proxy here is not much different from that in vue-cli2. It should be noted that there is an attribute ws: false in the HTTP request agent. Students who have used vue-cli3 may have found that if you do not add this attribute, the browser console will always report the error of not being able to connect to socket.

Finally, specify the host and port of the project in devServer, and then configure the proxy object.

On how to deal with cross-domain issues in Vue to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.