本文目錄

• 一 傳統的開(kāi)發(fā)模式
• 二 前后端分離的開(kāi)發(fā)模式
• 三 前后分離的優(yōu)點(diǎn)
• 四 JWT實(shí)現用戶(hù)認證
• 五 跨域問(wèn)題解決

回到目錄

一 傳統的開(kāi)發(fā)模式

前后端分離前我們的開(kāi)發(fā)協(xié)作模式一般是這樣的：

前端寫(xiě)好靜態(tài)的HTML頁(yè)面交付給后端開(kāi)發(fā)。靜態(tài)頁(yè)面可以本地開(kāi)發(fā)，也無(wú)需考慮業(yè)務(wù)邏輯只需要實(shí)現View即可。

后端使用模板引擎去套模板，同時(shí)內嵌一些后端提供的模板變量和一些邏輯操作。

然后前后端集成對接，遇到問(wèn)題，前臺返工，后臺返工。

然后在集成，直至集成成功。

這種模式的問(wèn)題

在前端調試的時(shí)候要安裝完整的一套后端開(kāi)發(fā)工具，要把后端程序完全啟動(dòng)起來(lái)。遇到問(wèn)題需要后端開(kāi)發(fā)來(lái)幫忙調試。我們發(fā)現前后端嚴重耦合，還要要求后端人員會(huì )一些HTML，JS等前端語(yǔ)言。前端頁(yè)面里還嵌入了很多后端的代碼。一旦后端換了一種語(yǔ)言開(kāi)發(fā)，簡(jiǎn)直就要重做。

像這種增加了大量的溝通成本，調試成本等，而且前后端的開(kāi)發(fā)進(jìn)度相互影響，從而大大降低了開(kāi)發(fā)效率。

回到目錄

二 前后端分離的開(kāi)發(fā)模式

前后端分離并不只是開(kāi)發(fā)模式，而是web應用的一種架構模式。在開(kāi)發(fā)階段，前后端工程師約定好數據交互接口，實(shí)現并行開(kāi)發(fā)和測試；在運行階段前后端分離模式需要對web應用進(jìn)行分離部署，前后端之前使用HTTP或者其他協(xié)議進(jìn)行交互請求。

1. 客戶(hù)端和服務(wù)端采用RESTFul API的交互方式進(jìn)行交互

2. 前后端代碼庫分離

在傳統架構模式中，前后端代碼存放于同一個(gè)代碼庫中，甚至是同一工程目錄下。頁(yè)面中還夾雜著(zhù)后端代碼。前后端工程師進(jìn)行開(kāi)發(fā)時(shí)，都必須把整個(gè)項目導入到開(kāi)發(fā)工具中。

前后端代碼庫分離，前端代碼中有可以進(jìn)行Mock測試(通過(guò)構造虛擬測試對 象以簡(jiǎn)化測試環(huán)境的方法)的偽后端，能支持前端的獨立開(kāi)發(fā)和測試。而后端代碼中除了功能實(shí)現外，還有著(zhù)詳細的測試用例，以保證API的可用性，降低集成風(fēng)險。

3. 并行開(kāi)發(fā)

在開(kāi)發(fā)期間前后端共同商定好數據接口的交互形式和數據格式。然后實(shí)現前后端的并行開(kāi)發(fā)，其中前端工程師在開(kāi)發(fā)完成之后可以獨自進(jìn)行mock測試，而后端也可以使用Postman等接口測試軟件進(jìn)行接口自測，然后前后端一起進(jìn)行功能聯(lián)調并校驗格式，最終進(jìn)行自動(dòng)化測試。

分離后，開(kāi)發(fā)模式是這樣的

回到目錄

三 前后分離的優(yōu)點(diǎn)

為優(yōu)質(zhì)產(chǎn)品打造精益團隊

通過(guò)將開(kāi)發(fā)團隊前后端分離化，讓前后端工程師只需要專(zhuān)注于前端或后端的開(kāi)發(fā)工作，是的前后端工程師實(shí)現自治，培養其獨特的技術(shù)特性，然后構建出一個(gè)全棧式的精益開(kāi)發(fā)團隊。

提升開(kāi)發(fā)效率

前后端分離以后，可以實(shí)現前后端代碼的解耦，只要前后端溝通約定好應用所需接口以及接口參數，便可以開(kāi)始并行開(kāi)發(fā)，無(wú)需等待對方的開(kāi)發(fā)工作結束。與此同時(shí)，即使需求發(fā)生變更，只要接口與數據格式不變，后端開(kāi)發(fā)人員就不需要修改代碼，只要前端進(jìn)行變動(dòng)即可。如此一來(lái)整個(gè)應用的開(kāi)發(fā)效率必然會(huì )有質(zhì)的提升。

完美應對復雜多變的前端需求

如果開(kāi)發(fā)團隊能完成前后端分離的轉型，打造優(yōu)秀的前后端團隊，開(kāi)發(fā)獨立化，讓開(kāi)發(fā)人員做到專(zhuān)注專(zhuān)精，開(kāi)發(fā)能力必然會(huì )有所提升，能夠完美應對各種復雜多變的前端需求。

增強代碼可維護性

前后端分離后，應用的代碼不再是前后端混合，只有在運行期才會(huì )有調用依賴(lài)關(guān)系。應用代碼將會(huì )變得整潔清晰，不論是代碼閱讀還是代碼維護都會(huì )比以前輕松。

使用了前后端分離架構后，除了開(kāi)發(fā)模式的變更，我們在開(kāi)發(fā)的過(guò)程中還會(huì )遇到哪些問(wèn)題呢？我們接著(zhù)往下看。

回到目錄

四 JWT實(shí)現用戶(hù)認證

我們先來(lái)看看傳統開(kāi)發(fā)，我們是如何進(jìn)行用戶(hù)認證的

前端登錄，后端根據用戶(hù)信息生成一個(gè)jsessionid，并保存這個(gè) jsessionid 和對應的用戶(hù)id到Session中，接著(zhù)把 jsessionid 傳給用戶(hù)，存入瀏覽器 cookie，之后瀏覽器請求帶上這個(gè)cookie，后端根據這個(gè)cookie值來(lái)查詢(xún)用戶(hù)，驗證是否過(guò)期。

HTTP有一個(gè)特性：無(wú)狀態(tài)的，就是前后兩個(gè)HTTP事務(wù)它們并不知道對方的信息。而為了維護會(huì )話(huà)信息或用戶(hù)信息，一般可用Cookie和Session技術(shù)緩存信息。

- Cookie是存儲在客戶(hù)端的

- Session是存儲在服務(wù)端的

但這樣做問(wèn)題就很多，如果我們的頁(yè)面出現了 XSS 漏洞，由于 cookie 可以被 JavaScript 讀取，XSS 漏洞會(huì )導致用戶(hù) token 泄露，而作為后端識別用戶(hù)的標識，cookie 的泄露意味著(zhù)用戶(hù)信息不再安全。盡管我們通過(guò)轉義輸出內容，使用 CDN 等可以盡量避免 XSS 注入，但誰(shuí)也不能保證在大型的項目中不會(huì )出現這個(gè)問(wèn)題。

在設置 cookie 的時(shí)候，其實(shí)你還可以設置 httpOnly 以及 secure 項。設置 httpOnly 后 cookie 將不能被 JS 讀取，瀏覽器會(huì )自動(dòng)的把它加在請求的 header 當中，設置 secure 的話(huà)，cookie 就只允許通過(guò) HTTPS 傳輸。secure 選項可以過(guò)濾掉一些使用 HTTP 協(xié)議的 XSS 注入，但并不能完全阻止。

httpOnly 選項使得 JS 不能讀取到 cookie，那么 XSS 注入的問(wèn)題也基本不用擔心了。但設置 httpOnly 就帶來(lái)了另一個(gè)問(wèn)題，就是很容易的被 XSRF，即跨站請求偽造。當你瀏覽器開(kāi)著(zhù)這個(gè)頁(yè)面的時(shí)候，另一個(gè)頁(yè)面可以很容易的跨站請求這個(gè)頁(yè)面的內容。因為 cookie 默認被發(fā)了出去。

解決方案

JWT（Json Web Token）

JWT 是一個(gè)開(kāi)放標準(RFC 7519)，它定義了一種用于簡(jiǎn)潔，自包含的用于通信雙方之間以 JSON 對象的形式安全傳遞信息的方法。該信息可以被驗證和信任，因為它是數字簽名的。JWTS可以使用秘密（使用HMAC算法）或公鑰/私鑰對使用RSA或ECDSA來(lái)簽名。

- 簡(jiǎn)潔(Compact)：可以通過(guò)URL, POST 參數或者在 HTTP header 發(fā)送，因為數據量小，傳輸速度快。

- 自包含(Self-contained)：負載中包含了所有用戶(hù)所需要的信息，避免了多次查詢(xún)數據庫。

JWT 組成

JWT由3個(gè)子字符串組成，分別為Header，Payload以及Signature，結合JWT的格式即：Header.Payload.Signature。（Claim是描述Json的信息的一個(gè)Json，將Claim轉碼之后生成Payload）。

Header 

Header是由下面這個(gè)格式的Json通過(guò)Base64編碼（編碼不是加密，是可以通過(guò)反編碼的方式獲取到這個(gè)原來(lái)的Json，所以JWT中存放的一般是不敏感的信息）生成的字符串，Header中存放的內容是說(shuō)明編碼對象是一個(gè)JWT以及使用“SHA-256”的算法進(jìn)行加密（加密用于生成Signature）

{
"typ":"JWT",
"alg":"HS256"
}

- 頭部包含了兩部分，token 類(lèi)型和采用的加密算法

- Base64是一種編碼，也就是說(shuō)，它是可以被翻譯回原來(lái)的樣子來(lái)的。它并不是一種加密過(guò)程。

Payload

Payload是通過(guò)Claim進(jìn)行Base64轉碼之后生成的一串字符串，Claim是一個(gè)Json，Claim中存放的內容是JWT自身的標準屬性，所有的標準屬性都是可選的，可以自行添加，比如：JWT的簽發(fā)者、JWT的接收者、JWT的持續時(shí)間等；同時(shí)Claim中也可以存放一些自定義的屬性，這個(gè)自定義的屬性就是在用戶(hù)認證中用于標明用戶(hù)身份的一個(gè)屬性，比如用戶(hù)存放在數據庫中的id，為了安全起見(jiàn)，一般不會(huì )將用戶(hù)名及密碼這類(lèi)敏感的信息存放在Claim中。將Claim通過(guò)Base64轉碼之后生成的一串字符串稱(chēng)作Payload。

{
"iss":"Issuer —— 用于說(shuō)明該JWT是由誰(shuí)簽發(fā)的",
"sub":"Subject —— 用于說(shuō)明該JWT面向的對象",
"aud":"Audience —— 用于說(shuō)明該JWT發(fā)送給的用戶(hù)",
"exp":"Expiration Time —— 數字類(lèi)型，說(shuō)明該JWT過(guò)期的時(shí)間",
"nbf":"Not Before —— 數字類(lèi)型，說(shuō)明在該時(shí)間之前JWT不能被接受與處理",
"iat":"Issued At —— 數字類(lèi)型，說(shuō)明該JWT何時(shí)被簽發(fā)",
"jti":"JWT ID —— 說(shuō)明標明JWT的唯一ID",
"user-definde1":"自定義屬性舉例",
"user-definde2":"自定義屬性舉例"
}

Signature

Signature是由Header和Payload組合而成，將Header和Claim這兩個(gè)Json分別使用Base64方式進(jìn)行編碼，生成字符串Header和Payload，然后將Header和Payload以Header.Payload的格式組合在一起形成一個(gè)字符串，然后使用上面定義好的加密算法和一個(gè)密匙（這個(gè)密匙存放在服務(wù)器上，用于進(jìn)行驗證）對這個(gè)字符串進(jìn)行加密，形成一個(gè)新的字符串，這個(gè)字符串就是Signature。

簽名的目的：最后一步簽名的過(guò)程，實(shí)際上是對頭部以及負載內容進(jìn)行簽名，防止內容被竄改。如果有人對頭部以及負載的內容解碼之后進(jìn)行修改，再進(jìn)行編碼，最后加上之前的簽名組合形成新的JWT的話(huà)，那么服務(wù)器端會(huì )判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負載進(jìn)行簽名，在不知道服務(wù)器加密時(shí)用的密鑰的話(huà)，得出來(lái)的簽名也是不一樣的。

三個(gè)部分通過(guò).連接在一起就是我們的 JWT 了：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ.PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s

JWT認證

服務(wù)器在生成一個(gè)JWT之后會(huì )將這個(gè)token發(fā)送到客戶(hù)端機器，在客戶(hù)端再次訪(fǎng)問(wèn)受到JWT保護的資源URL鏈接的時(shí)候，服務(wù)器會(huì )獲取到這個(gè)token信息，首先將Header進(jìn)行反編碼獲取到加密的算法，在通過(guò)存放在服務(wù)器上的密匙對Header.Payload 這個(gè)字符串進(jìn)行加密，比對token中的Signature和實(shí)際加密出來(lái)的結果是否一致，如果一致那么說(shuō)明該token是合法有效的，認證成功，否則認證失敗。

JWT使用總結

1. 首先，前端通過(guò)Web表單將自己的用戶(hù)名和密碼發(fā)送到后端的接口。這一過(guò)程一般是一個(gè)HTTP POST請求。建議的方式是通過(guò)SSL加密的傳輸（https協(xié)議），從而避免敏感信息被嗅探。

2. 后端核對用戶(hù)名和密碼成功后，將用戶(hù)的id等其他信息作為JWT Payload（負載），將其與頭部分別進(jìn)行Base64編碼拼接后簽名，形成一個(gè)JWT。形成的JWT就是一個(gè)形同lll.zzz.xxx的字符串。

3. 后端將JWT字符串作為登錄成功的返回結果返回給前端。前端可以將返回的結果保存在Cookie或localStorage或sessionStorage上，退出登錄時(shí)前端刪除保存的JWT即可。

4. 前端在每次請求時(shí)將JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問(wèn)題)

5. 后端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正確；檢查T(mén)oken是否過(guò)期；檢查T(mén)oken的接收方是否是自己（可選）。

6. 驗證通過(guò)后后端使用JWT中包含的用戶(hù)信息進(jìn)行其他邏輯操作，返回相應結果。

JWT和Session方式存儲id的差異

Session方式存儲用戶(hù)id的最大弊病在于Session是存儲在服務(wù)器端的，所以需要占用大量服務(wù)器內存，對于較大型應用而言可能還要保存許多的狀態(tài)。一般而言，大型應用還需要借助一些KV數據庫和一系列緩存機制來(lái)實(shí)現Session的存儲。

而JWT方式將用戶(hù)狀態(tài)分散到了客戶(hù)端中，可以明顯減輕服務(wù)端的內存壓力。除了用戶(hù)id之外，還可以存儲其他的和用戶(hù)相關(guān)的信息，例如該用戶(hù)是否是管理員、用戶(hù)所在的分組等。雖說(shuō)JWT方式讓服務(wù)器有一些計算壓力（例如加密、編碼和解碼），但是這些壓力相比磁盤(pán)存儲而言可能就不算什么了。

單點(diǎn)登錄

Session方式來(lái)存儲用戶(hù)id，一開(kāi)始用戶(hù)的Session只會(huì )存儲在一臺服務(wù)器上。對于有多個(gè)子域名的站點(diǎn)，每個(gè)子域名至少會(huì )對應一臺不同的服務(wù)器，例如：

www.taobao.com，nv.taobao.com，nz.taobao.com，login.taobao.com。所以如果要實(shí)現在login.taobao.com登錄后，在其他的子域名下依然可以取到Session，這要求我們在多臺服務(wù)器上同步Session。使用JWT的方式則沒(méi)有這個(gè)問(wèn)題的存在，因為用戶(hù)的狀態(tài)已經(jīng)被傳送到了客戶(hù)端。

回到目錄

五 跨域問(wèn)題解決

當客戶(hù)端和服務(wù)端分開(kāi)部署到不同服務(wù)器的時(shí)候，就會(huì )遇到跨域訪(fǎng)問(wèn)的問(wèn)題，是由瀏覽器同源策略限制的一類(lèi)請求場(chǎng)景。

跨域解決方案有很多種，下面使用Nginx反向代理的方案

反向代理

代理訪(fǎng)問(wèn)其實(shí)在實(shí)際應用中有很多場(chǎng)景，在跨域中應用的原理做法為：通過(guò)反向代理服務(wù)器監聽(tīng)同端口，同域名的訪(fǎng)問(wèn)，不同路徑映射到不同的地址，比如，在nginx服務(wù)器中，監聽(tīng)同一個(gè)域名和端口，不同路徑轉發(fā)到客戶(hù)端和服務(wù)器，把不同端口和域名的限制通過(guò)反向代理，來(lái)解決跨域的問(wèn)題：

server {
listen       80;
server_name  domain.com;
#charset koi8-r;
#access_log  logs/host.access.log  main;
location /client { #訪(fǎng)問(wèn)客戶(hù)端路徑
proxy_pass http://localhost:81;
proxy_redirect default;
    }
location /apis { #訪(fǎng)問(wèn)服務(wù)器路徑
rewrite  ^/apis/(.*)$ /$1 break;
proxy_pass   http://localhost:82;
    }
}