爲什麼要使用proxyTable
- 瀏覽器的同源策略不允許跨域訪問,所謂同源策略是指協議、域名、端口相同
- 在平時項目的開發環境中,經常會遇到跨域的問題,尤其是使用vue-cli這種腳手架工具開發時,由於項目本身啓動本地服務是需要佔用一個端口的,所以必然會產生跨域的問題。在使用webpack做構建工具的項目中使用proxyTable代理實現跨域是一種比較方便的選擇。
如何使用proxyTable
還是拿之前使用過的vue-cli舉例。我們首先要找到根目錄下config文件夾下的index.js文件。由於我們是在開發環境下使用,自然而然是要配置在dev裏面:
dev: {
...
proxyTable: {
'/api': {
target: 'http://www.abc.com', // 目標接口域名
changeOrigin: true, // 是否跨域
pathRewrite: {
'^/api': '/api' // 重寫接口
}
}
}
...
}
上面這段代碼的效果就是將以/api
字段起始的本地接口請求代理到了http://www.abc.com
這一域名下:
'http://localhost:8080/api' ===> 'http://www.abc.com/api'
沒有統一項目名下的使用
上面那種情況是有一個統一的項目名api的,所以說是比較好匹配的,就相當於說直接將以api開頭的接口名代理一下換成目標域名訪問就好了,可是如果說後臺返給我們前端的接口沒有了統一的項目名如何處理呢?
//先人爲給接口地址前面加上一個自定義的項目名
let someApi = '/api' + '/xx/xx';
dev: {
...
proxyTable: {
'/api': {
target: 'http://www.abc.com', //目標接口域名
changeOrigin: true, //是否跨域
pathRewrite: {
'^/api': '/' //重寫接口
}
}
}
...
}
這裏的項目名api是我們人爲加上去的,經過代理之後就沒了,這樣我們在配置代理這裏只需要配置一份就夠了,只是在寫接口地址時要注意區分開發環境和線上環境就可以了。
關於proxyTable的原理
同源策略是瀏覽器需要遵循的標準,而如果是服務器向服務器請求就無需遵循同源策略。vue-cli的proxyTable用的是http-proxy-middleware中間件,該中間件本質上是在本地開了一個服務器dev-server,所有的請求都通過這裏轉發出去,即把瀏覽器的發送請求代理轉發到代理服務器上,再由代理服務器發送請求給目標服務器,從而解決跨域問題。
遇到跨域問題的場景有很多,只要是做前端開發,總會遇到。解決方案也是多種多樣,如jsonp、cors、websocket、nginx反向代理,也包括上面用到的node中間件代理,等等,各有差異。在實際開發中,更多是使用代理來避免同源策略。