Maison >interface Web >Questions et réponses frontales >Package et déploiement de Vue sur tous les domaines
Avant-propos
Dans le développement de projets, nous sommes souvent confrontés à des problèmes inter-domaines. Parce que le nom de domaine que nous utilisons n'est pas cohérent avec le nom de domaine de l'interface back-end, des problèmes inter-domaines se produiront. Dans l'environnement de développement, nous pouvons résoudre les problèmes inter-domaines en configurant le proxy, mais après l'empaquetage et le déploiement, nous devons utiliser d'autres méthodes pour résoudre les problèmes inter-domaines. Cet article explique comment utiliser vue-cli3 pour empaqueter et déployer plusieurs domaines.
1. Qu'est-ce que l'origine croisée
Le partage de ressources d'origine croisée (CORS) est une limitation de la politique de même origine du navigateur, qui empêche les pages Web d'obtenir des ressources provenant d'autres sources, ce qui signifie que deux pages ont exactement la même origine. le même protocole, nom de domaine et numéro de port. Si une requête est lancée à partir d'un chemin source non original, le navigateur rejettera la requête.
2. Plusieurs modes de packaging de vue-cli3
Dans vue-cli3, le packaging est divisé en trois modes :
3. Empaqueter et déployer des solutions inter-domaines
Lors de l'empaquetage et du déploiement inter-domaines, nous devons utiliser nginx pour effectuer un proxy inverse afin de résoudre les problèmes inter-domaines.
nginx est un serveur Web hautes performances qui peut fonctionner sur divers systèmes d'exploitation tels que Windows, Linux et Mac. Il est très puissant et peut être utilisé pour le proxy inverse, l’équilibrage de charge, la mise en cache, etc.
Dans un environnement Linux, nous pouvons installer nigix via la commande suivante :
sudo apt-get update sudo apt-get install nginx
Après avoir installé nginx, nous devons configurer nginx pour résoudre les problèmes inter-domaines.
Tout d'abord, nous devons trouver le fichier de configuration nginx, généralement dans /etc/nginx/conf.d/default.conf. Nous ouvrons le fichier de configuration nginx via la commande suivante :
sudo vim /etc/nginx/conf.d/default.conf
Ensuite, recherchez le segment du serveur, comme suit. :
server { listen 80; server_name localhost; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; location / { root /usr/share/nginx/html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ .php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # #location ~ .php$ { # root html; # fastcgi_pass 127.0.0.1:9000; # fastcgi_index index.php; # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; # include fastcgi_params; #} # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /.ht { # deny all; #} }
Nous devons configurer le proxy inverse sous le segment d'emplacement, par exemple :
location /api { proxy_pass http://192.168.0.100:8080; # 后端API地址 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_http_version 1.1; proxy_connect_timeout 600; proxy_read_timeout 600; proxy_send_timeout 600; proxy_buffer_size 64k; proxy_buffers 4 64k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 128k; # 解决跨域 add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Authorization,DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type'; # 缓存时间,单位秒。这里设置的是6小时 expires 21600s; # 收到304响应后,再次请求的时间间隔 proxy_cache_valid 200 304 12h; }
Parmi eux, l'adresse après proxy_pass doit être remplacée par l'adresse de votre API backend, et add_header résout le problème inter-domaines.
Dans vue-cli3, nous pouvons configurer publicPath dans vue.config.js pour rendre les fichiers packagés indépendants du nom de domaine. La configuration spécifique est la suivante :
module.exports = { publicPath: '', devServer: { // 设置跨域代理 proxy: { '/api': { target: 'http://192.168.0.100:8080', // 后端API地址 ws: true, changOrigin: true, pathRewrite: { '^/api': '' } } } }, chainWebpack: (config) => { config.optimization.delete('splitChunks'); } }
Parmi. eux, /api est le préfixe de l'adresse de l'API backend et la configuration cible est l'adresse de l'API backend.
Après la configuration ci-dessus, nous pouvons empaqueter et déployer le projet vue. Une fois le packaging terminé, nous copions tous les fichiers du répertoire /dist dans le répertoire racine de la configuration nginx, généralement /usr/share/nginx/html, puis nous redémarrons le service nginx :
sudo service nginx restart
À ce stade, nous avons réussi à implémenter le packaging et le déploiement de vue-cli3 sur tous les domaines.
Résumé
Cet article explique comment utiliser le proxy inverse nginx pour résoudre le problème inter-domaines de l'empaquetage et du déploiement de vue-cli3. Grâce à la configuration ci-dessus, nous pouvons résoudre le problème inter-domaines et le déployer dans l'environnement de production. Bien entendu, nous devons prêter attention aux problèmes de sécurité pendant le processus de déploiement, tels que l'activation des autorisations d'accès utilisateur pour nginx, etc. Bien entendu, nous pouvons également utiliser d'autres méthodes pour résoudre des problèmes inter-domaines, telles que : jsonp, websocket, etc.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!