關於前端的一些問題

            最近項目剛剛上線,到目前爲止還算比較順利,雖然中間磕磕絆絆的出現一些問題,但是也都一一解決。把相關的問題在這裏做一個整理吧,也反思一些在項目中出現的問題進行如何解決。

            第一部分:H5頁面兼容性

                在項目開始的時候,前端除了採用zepto之外,還考慮提升用戶體驗,引用了一個第三方的插件。整個項目測試的過程中,出現了兩個問題:引用的第三方插件在部分安卓,ios上出現異常;弱網環境下js加載緩慢。

               該項目在正常情況下各項功能正常,但是在實際的應用中部分ios機型出現了異常,而且在弱網環境的應用場景下出現了一些問題。最後,通過測試決定不使用第三方插件,調用系統的控件,問題解決。

               總結:

               在H5項目中,因爲實際的用戶場景大部分是移動應用,而移動應用很多時候網絡並不是總能保持穩定。這個時候,就充分的體現出在移動場景下,最重要的因素:兼容性和引用文件的大小。

              目前安卓的碎片化嚴重,甚至部分廠商進行自定義的系統修改,很多時候,會出現部分機型異常或者出現各種無法預計的問題。尤其在追求用戶體驗的過程中,不能捨本求末,必須在不影響用戶使用的情況下,做到最優的程度。當出現一部分機型的用戶無法正常使用的時候,通常需要考慮能否承擔起損失這部分用戶的風險。同樣的在涉及到ios的時候,因爲其系統的特殊性,也會出現一些因爲兼容或則ios系統的機制不同而產生的問題,這些在開發的過程中都是需要充分考慮的因素。在該項目上線時,經過最後的取捨,總共4個引用js,平均大小不到20K,弱網情況下js加載緩慢的問題,也基本上得到解決。我對比了一下最新的jQuery Mobile,其單個文件就超過了100K,雖然在普通情況下問題不大,但是一旦出現極限應用場景,兩者的體驗還是能看出明顯的差異。這也是大部分移動項目採用zepto優先jQuery Mobile的原因。


            第二部分:前端加密

                  在這個項目之前,所有做過的涉及移動端的項目都是簡單的寫業務邏輯,提供接口給APP端,具體的實現和請求由APP進行處理。在移動端發起的請求,在這種情況下,都由移動端負責加密和安全的問題。此次的H5項目因爲是在APP內嵌H5的頁面,因此從前端的頁面展示和參數的傳遞都由服務端來進行控制,因此涉及到了平時沒有特別重視的加密問題。

                  在進行項目開發的時候,具體的涉及到了兩個比較重要的問題:1. 在進行請求發起的時候,因爲沒有調用系統的簽名驗證,導致請求沒有安全過濾; 2. 在傳遞參數的時候,涉及到用戶的敏感信息,沒有做加密處理,導致用戶信息明文傳遞。

                  首先是簽名驗證的問題,其實在該項目開始的時候,也比較倉促,開發的時間被壓縮了很多,也並沒有在開始種充分考慮到安全問題。在使用系統的簽名驗證過程中出現了一些問題。整個項目如果嚴格按照流程,應該是有兩層簽名驗證的過程。第一層是H5頁面加載進入首頁的時候,需要對頁面的參數和簽名進行驗證。第二層是在頁面用戶填好信息之後,發起請求的時候,調用系統簽名對請求進行驗證。本人在剛開始的時候,第一版就直接沒有進行第一層的驗證,導致的結果就是在除了APP內部,在外部也可以進行頁面的訪問,這樣做,從嚴格的安全上來說是有隱患的。但是考慮到在以後業務經過正常的發展之後,還有可能將H5放到微信或者外部,這個地方也做了準備。如果需要的話,這第一層的校驗則失去了必要。第二層簽名驗證的同時,還有一個用戶敏感信息加密的問題。這裏剛開始的時候,我並沒有特別在意這個,只是進行了簡單的轉碼和encode,但是這樣的結果就是在傳遞的過程中還是有可能被攔截和修改參數,因此重新對信息進行了轉碼+二次加密。

                  總結:

                  項目正式上線的時候,加上了頁面加載和請求發起兩層簽名校驗,同時,前端採用了一個開源的js加密庫----Crypto-js,用了其中的一種算法,對用戶的敏感信息進行了加密。具體的加密和解密方法這裏不做詳細描述。但是表達一下個人的感言,crypto-js確實用起來很方便。也推薦大家以後如果在做項目的時候涉及到類似的需求,也可以試一試。另外知乎上曾經看到有人對前端是否需要加密的問題進行大肆的討論,第一名的竟然是前端加密毫無意義的結論。我覺得吧,有些問題,不能一葉障目的去看待。本質上來說,給定一定的時間和資源,一切加密都是無效的,但是這裏畢竟還涉及到一個解密成本的問題,如果真的都沒有意義。那估計得等到量子計算機搞出來,或者P?=NP問題被解決之後吧。

            第三部分:關於接口調用

                  其實關於接口的調用沒有太多可講的東西,但是之前有做Restful Api,到了手頭的這個項目似乎又迴歸了古老的模式。往深入的說,其實涉及的是計算機之間的通信,以及以什麼樣的角度來看待對計算資源的訪問。以後有機會的話,再深入講一講個人關於計算資源的理解。

            第四部分:關於架構

                  架構這個東西,很多時候看上去都是很虛的。但是在實際的開發過程中,整個項目在開始時候的架構的設計直接關係到項目中後期開發的效率,項目運行效率,時間成本等方面。這裏個人決定還是把這一部分單獨提出來,另外形成一篇文章。這裏不做贅述。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章