vueプロジェクトは包装後、どのように優雅にクロスドメインを解決しますか？

3332 ワード

vue アイテム包装する国境をまたぐ

前言
vue.jsを使ってフロントエンドプロジェクトを開発する時、webpackと関連して各種のプラグインを開発して、フロントエンドの開発に多くの便利さをもたらしました。クロスドメインの問題を解決する上で、vue.jsのフロントエンド同僚達が私と同じように味を味わったと信じています。開発環境は全部proxyTableに頼っています。まだよく分かりませんので、初心者はまだ私の言っていることが分かりません。次のような配置です。


proxyTable: {
   '/api': {
    target: 'http://113.113.113.113:5000', //       
    changeOrigin: true,
    pathRewrite: {
     '^/api': ''
    }
   },

私たちのクロスドメインはこのように完璧に解決されました。そしてバックエンドのインターフェースを楽しくお願いします。
本題にもどる
具体的なシーン：会社のH 5プロジェクトはクライアントに展開されていますが、展開後にバグが発生しました。複数の人が共同開発して、しかも進捗状況がパッケージ化されたため、CSSの問題で複数のページのレイアウトが乱れました。じゃ、distの下のindex.を開けて見てください。bugを再現してください。何も考えなくてもいいです。ページにはデータがないです。どうやって再現したらいいですか？また偽のデータを作りに行きますか？このように振り回されるのが嫌な人としては、必ずこのようなことはしたくないです。
後端を煩わすことなく、自分で解決します。
inxはやはりいくつかのができて、自分で配置して、分を分けて解決して、はは！


server {
    listen    8082;
    server_name 127.0.0.1; //   nginx     

    #charset koi8-r;

    #access_log logs/host.access.log main;

    location / {
      root  html;
      index index.html index.htm;
    }
  location /app-api {
      rewrite ^.+app-api/?(.*)$ /$1 break;
      include uwsgi_params;
      proxy_pass  http://113.113.113.113:5001/; //      
      //    start
      add_header Access-Control-Allow-Origin *;
      add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
      add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,token';
      //    end
      //      nginx     
      #Proxy Settings
      proxy_redirect   off;
      proxy_set_header  Host       $host;
      proxy_set_header  X-Real-IP    $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header  Connection    close;
      proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
      proxy_max_temp_file_size 0;
      proxy_connect_timeout   90;
      proxy_send_timeout     90;
      proxy_read_timeout     90;
      proxy_buffer_size     4k;
      proxy_buffers       4 32k;
      proxy_busy_buffers_size  64k;
      proxy_temp_file_write_size 64k;
    }
}

目的はバックエンドインターフェースをnginxでもう一度代行します。私達は直接にnginxでクロスドメイン要求を許可します。
start nginx//inxディレクトリでサービスを開始します。
通常、私達は統一的な管理インターフェースのjsファイルを作ります。


var BASE_URL = '/api';
var isPro = process.env.NODE_ENV === 'production'
if(isPro){
 BASE_URL= 'http://113.113.113.113:5000', //        
 //BASE_URL= 'http://127.0.0.1:8020', //nginx    
 //                        
}
const UrlConfig = {
 getToken:BASE_URL + "   "
}
export default {
 UrlConfig
};

これで、包装後のインターフェースの問題を優雅に解決しました。
おわりに
会社の前後のエンドプロジェクトは通常同じサーバーに置くか、それとも同じサーバーにいない時にドメインをまたぐのもバックエンドの同志達によって解決するので、生産環境の中で先端によってドメインを跨ぐこの需要を解決するのは少ないです。しかし、私が共有しているこの小さな技術は上記のようなシーンにしか適用されません。結局、多くの人が共同開発する過程で、公共及び個人のプログラミング規範を事前に計画して、できるだけ開発環境と生産環境が一致していることを保証します。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。

WINDOWSで計画タスクを設定し、PHPファイルを実行する方法

LinuxのCrontabタイミングでPHPスクリプトを実行する方法