在https中引入http資源所導致的問題

廣州蘆葦科技web前端發表於2018-12-24
HTTP

前言

最近在週報系統和格子機專案中都出現了在測試服能夠正常執行，部署到正式服之後就出現問題，這些問題的原因就是：一般測試服都沒有安全性的需求，所以都是使用http協議。但是正式服現在一般都是使用更加安全的https協議。

問題

問題的關鍵就是在於這個協議的問題，瀏覽器預設是不允許在https裡面呼叫http資源的。在這裡根據我所遇到的情況大概是這樣子的：

  1. 在IE瀏覽器瀏覽器中使用連結載入資源時會彈出一個對話方塊：
avatar
  1. 在微信的瀏覽器中引入圖片資源時會報一個警告(但是圖片會正常載入)：
avatar
  1. 在https頁面中向http地址發起ajax請求時，瀏覽器會阻止掉這個請求，然後報一個Mixed Content的錯誤。
  2. 在https頁面中使用webSocket時需要注意，必須使用wss協議才能夠發起連線，不然也會報錯：
avatar

問題分析

https協議與https協議的區別

在解決這個問題之前首先需要知道https是什麼，與http的區別在什麼地方。

https安全超文字傳輸協議：

它是一個安全通訊通道，它基於HTTP開發，用於在客戶計算機和伺服器之間交換資訊，它使用安全套接字層(SSL)進行資訊交換，簡單來說它是HTTP的安全版。它是由Netscape開發並內建於其瀏覽器中，用於對資料進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用埠443，而不是象HTTP那樣使用埠80來和TCP/IP進行通訊。）SSL使用40 位關鍵字作為RC4流加密演算法，這對於商業資訊的加密是合適的。HTTPS和SSL支援使用X.509數字認證，如果需要的話使用者可以確認傳送者是誰。總的來說，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議要比http協議安全。

在URL前加https://字首表明是用SSL加密的，你的電腦與伺服器之間收發的資訊傳輸將更加安全。 Web伺服器啟用SSL需要獲得一個伺服器證書並將該證書與要使用SSL的伺服器繫結。

https與http的區別：

  • https協議需要到ca申請證書，一般免費證書很少，需要交費。
  • http是超文字傳輸協議，資訊是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。
  • http和https使用的是完全不同的連線方式用的埠也不一樣,前者是80,後者是443。
  • http的連線很簡單,是無狀態的。
  • HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議 要比http協議安全。

什麼是混合內容（Mixed Content）

很明顯上面報的錯都是與Mixed Content是有關係的，Mixed Content就是：

當使用者訪問使用HTTPS的頁面時，他們與web伺服器之間的連線是使用SSL加密的，從而保護連線不受嗅探器和中間人攻擊。

如果HTTPS頁面包括由普通明文HTTP連線加密的內容，那麼連線只是被部分加密：非加密的內容可以被嗅探者入侵，並且可以被中間人攻擊者修改，因此連線不再受到保護。當一個網頁出現這種情況時，它被稱為混合內容頁面。

詳情可見：developer.mozilla.org/zh-CN/docs/…

解決方案

相對協議

如果你的網站同時準備了https資源和http資源，那麼使用相對協議可以實現根據當前網站的協議，瀏覽器自行選擇通過https還是http發起請求，而相對協議也是非常簡單的就是講URL的協議(http、https)去掉。<
img src="//domain.com/img/logo.png">

這裡一定要注意必須是網站同時有https和http的資源才會有效，否則請求會失敗，另外一般在正式服上線時都會劉改HOST地址，所以一般的ajax請求並不會出現問題，主要要注意的是一些單獨的請求地址會出現這樣的問題，如七牛雲上傳所使用的地址是單獨的，所以有可能在正式服上線時沒有注意到，另外就是使用websocket時檢查一下正式服的socket地址是否是wss協議。

總結

這次第一個出現的問題是在週報系統七牛上傳檔案部分出現的，由於之前週報系統正式服可以通過http訪問到，所以沒有出現問題，但是最近正式服換成了https，就導致檔案無妨上傳，當時在碰到問題時感覺比較奇怪，明明測試服是正常的，為什麼正式服會不正常，由於沒有正式服的賬號，所以除錯的時候是在別人的電腦上面，當時控制檯好像並沒有列印報錯資訊（有可能是自己沒有注意到），只是發現了在上傳檔案時的第二個請求無法傳送出去，當時也並沒有狀態碼（這裡其實是請求根本就沒有傳送出去，被瀏覽器給block掉了）。所以在解決問題的時候並沒有一個方向，最後是在老大的幫助下才瞭解到問題的所在的。

而在這一次問題中暴露出了一些問題，比如：

  1. 在確定測試服正常的情況下自我感覺正式服應該不會有錯，帶著這樣的心理去找問題就會忽視掉很多的細節問題。
  2. 當時只是發現請求沒傳送出去，卻沒有去找請求傳送失敗的原因。
  3. 沒有去尋找控制檯的報錯資訊（當時沒有發現有錯誤資訊，不知道是使用者瀏覽器的問題還是自己疏忽了，這個是本次沒有找到問題根源的關鍵所在），只是去關注了Network皮膚請求傳送情況。

第二次是格子機的socket連線失敗，這個問題主要是自己在拿到後端給的正式服socket地址時沒有檢查，沒有發現地址的協議是ws的導致在測試時才發現這個問題，在以後拿到後端給的地址時還是需要檢查一下再去使用。

參考資料

作者簡介：李成文，蘆葦科技web前端開發工程師，擅長網站建設、微信公眾號開發、微信小程式開發、小遊戲製作、企業微信製作、H5建設，專注於前端框架、互動設計、影像繪製、資料分析等研究。

個人部落格：LCW blog

歡迎和我們一起並肩作戰： web@talkmoney.cn訪問 www.talkmoney.cn 瞭解更多

提供深圳微信公眾號製作，廣東釘釘開發，專業的企業微信外包，高價效比的微信小程式建設，靠譜的小遊戲製作，高質量的H5開發

來源：https://juejin.im/post/5c204153e51d45351c4f21e4

相關文章