這是 Jerry 2021 年的第 50 篇文章，也是汪子熙公眾號總共第 327 篇原創文章。

今天文章提到的場景，理論上本公眾號每一位粉絲，都可以在自己的電腦上進行操作。因為涉及到的應用，幾乎每一個人日常生活中都會使用到——淘寶網。

Jerry 負責的是 SAP Commerce Cloud 前臺開發，為何要寫和淘寶網相關的文章？

上個週日即7月25日凌晨兩點半，Jerry 所在的 Spartacus 開發團隊，收到了一個客戶 escalation.

![](https://img-blog.csdnimg.cn/img_convert/e8d8ad4bc50ee1db3eeac0c4b3f8acdb.png)

這個客戶 incident 和會話管理 (Session Management) 相關，因此 Jerry 一邊和同事處理問題，一邊不禁聯想起，作為另一款國內外數一數二的電商網站，淘寶網是如何處理類似問題的？

在電腦端訪問淘寶網，輸入淘寶使用者名稱和密碼，點選登入：

![](https://img-blog.csdnimg.cn/img_convert/21edeeb5ad7fdd5e04c6ecd5f109923c.png)

會觀察到一個 HTTP Post 請求，login，傳送往後臺伺服器：

https://login.taobao.com/newlogin/login.do?appName=taobao&fromSite=0

![](https://img-blog.csdnimg.cn/img_convert/bdcb3c2eef2ece49f4b12bd0a5a30d8b.png)

該請求的 Form Data 中包含 loginId 和 password2 兩個欄位，分別維護了使用者輸入的淘寶使用者名稱的明文，以及淘寶密碼進行 RSA 加密後的值。

下面介紹如何自行找到淘寶網前端將使用者輸入的登入密碼進行 RSA 加密的準確位置。

在 Chrome 開發者工具裡找到 login 請求，在 Initiator 皮膚裡找到發起該請求的呼叫棧。稍有經驗的前端開發人員，從 onClick 和 t.loginSubmit 就能推斷出，使用者名稱和密碼的輸入框，實現在一個 Form 表單裡，點選登入按鈕後，觸發表單的 Submit.

![](https://img-blog.csdnimg.cn/img_convert/905e9ef3bd0cf2d61fac8e45f6f2e686.png)

開啟上圖找到的 index.js 檔案：

https://x.alicdn.com/vip/havana-nlogin/0.5.61/index.js

直接搜尋關鍵字 password2，很快就能找到 RSA 加密的程式碼位置：
![](https://img-blog.csdnimg.cn/img_convert/1ab9d3332d876f52b488afc1c05cb431.png)

設定斷點後，執行時點選登入按鈕，斷點觸發，可以進入 rsaPassword 函式，檢視 RSA 加密演算法的明細。

![](https://img-blog.csdnimg.cn/img_convert/ef4f59c78c5313d59aaa9c5645738df5.png)

這個 index.js 裡還能發現一些有趣的東西。比如提供了 rsaPassword 方法的模組內部，還維護了一個支援的國家列表，countryList，裡面有 168 個國家和地區：

![](https://img-blog.csdnimg.cn/img_convert/edd415b6079a2069a082038bc47e1dda.png)

但是在瀏覽器端開啟淘寶網，國家和地區的下拉選單裡，只能看到十餘條記錄。這應該是前臺某處根據某種邏輯做了過濾：

![](https://img-blog.csdnimg.cn/img_convert/909b215001f80a6d882a6d03fe7d448e.png)

此外，我們在淘寶網首頁右邊區域，能看到快速充值話費的皮膚，如下圖綠色高亮區域所示：

![](https://img-blog.csdnimg.cn/img_convert/118ba04009fa2d110344c127db4d0ec8.png)

該頁面的 HTML 原始碼，並不是靜態編寫於首頁的 HTML 檔案中，而是透過一個叫做 bianming-phone("便民"的拼音加上"手機"的英文單詞 phone，這混搭風格......) 的 HTTP 請求，從後臺讀取到前臺，然後再注入到前臺頁面中：

![](https://img-blog.csdnimg.cn/img_convert/4d562342ccc76b20494b17b4fd90bc29.png)

同理，還有這個旅行檢視片段(相當於 SAP UI5 裡的 View Fragment)：

![](https://img-blog.csdnimg.cn/img_convert/dfe24c6fc1fb5e631496b121a31d9fb4.png)

讀取該檢視片段的 HTTP 請求：bianming-trip

![](https://img-blog.csdnimg.cn/img_convert/be0cafcec87a31a0306812f99e31c796.png)

看到這裡，Jerry 不由得聯想起 SAP Commerce Cloud 前臺的 CMS 驅動設計，二者都是從電商頁面連線的後臺系統讀取部分頁面配置資訊，可謂異曲同工。

SAP S/4HANA 的 UI 風格是 Fiori UX，實現的前端框架是 SAP UI5；SAP Commerce Cloud UI 實現的前端框架是 Angular；

help.sap.com 採用 AngulaJS 實現，www.sap.com 使用的是 React.詳情參考 Jerry 的文章：[**SAP官方幫助網站，help.sap.com 背後那些事兒**](http://mp.weixin.qq.com/s?__biz=MzI3MDE4MjM5Mg==&mid=2247491673&idx=1&sn=6798ba86320530f2180d03ae547218c9&chksm=ead652cedda1dbd816dfd09169d1240badeec3457cd12fd3d0eaf1e3b930b0c07a65cf3b2458&scene=21#wechat_redirect)。

而淘寶網首頁，採用的是阿里自研的前端框架，Kissy：

![](https://img-blog.csdnimg.cn/img_convert/ad6f09f3a1bc9c8c04de7acb492bab76.png)

![](https://img-blog.csdnimg.cn/img_convert/3f6cfb1cd24dfa608a322b6f12f85f6e.png)

我們在淘寶網首頁看到琳琅滿目的商品圖片，都是被 Kissy 驅動，透過向 CDN 伺服器發起的資料請求而被載入的：

![](https://img-blog.csdnimg.cn/img_convert/d6e3226b8870f771f474604fb988e06d.png)

在這些頁面片段的原始碼裡還看到一些有意思的內容，比如這種“上線請刪除”的註釋。我現在瀏覽的就是上線後的程式碼呀，咋還能夠看到這些註釋 :)

![](https://img-blog.csdnimg.cn/img_convert/ad65511847d82585c686e29ec4f7011b.png)

還有這種給 window 全域性物件新增 flag 屬性，賦值為 5 的做法。 作為同行，我非常能理解這種 workaround :)

![](https://img-blog.csdnimg.cn/img_convert/3e738513f88546306b80665037f56e93.png)

想起有一段在國外程式設計師界很流行的註釋，翻譯成中文大意是：

// 下面這段程式碼不要動，因為只有我和上帝，知道這段程式碼在幹啥
// 現在，只有上帝知道這段程式碼在幹啥

我們在淘寶網上購物時，選擇好了自己心儀的商品，加入購物車之後，當然不希望點選結帳之後，忽然彈出要求重新登入的介面，這豈不是令人掃興。另外，當我們不小心誤操作，點選了瀏覽器重新整理按鈕，我們期望頁面重新整理後，仍然處於登入狀態，之前新增到購物車裡的商品不會丟失。這些都屬於使用者會話管理的範疇。

淘寶網頁面的使用者會話管理，是透過客戶端 Cookie 和伺服器端維護的使用者會話物件來實現的。

使用者成功登入淘寶網之後，伺服器建立對應的 Session 物件，返回給 login HTTP 請求的響應頭部，包含了很多 set-cookie 欄位：

![](https://img-blog.csdnimg.cn/img_convert/3967fa8dd0a957eecce2cd3b6558755e.png)

瀏覽器解析這些響應，將伺服器頒發的 Cookie 設定到本地。下一次使用者操作淘寶網，觸發新的發向伺服器端的請求時，瀏覽器會自動將這些 Cookie 欄位設定到請求頭部。伺服器接收到這些 Cookie 欄位，就能在記憶體中定位到之前該使用者登入後對應建立的 Session 物件，從而能夠識別出該使用者。

![](https://img-blog.csdnimg.cn/img_convert/79ae01cb160e95852d18b1c338fd92ea.png)

這些 Cookie 在 Chrome 開發者工具裡也能檢視。

(1) Cookie 的 Expires 欄位存放的是過期時間，當 Expires 為 Session 時，意為該 Cookie 只在當前會話內有效，瀏覽器關閉則 Cookie 自動刪除。

(2) 帶有 Http Only 的 Cookie，無法被客戶端 JavaScript 程式碼讀取，提高了安全性，避免了 Cookie 透過 XSS 攻擊被竊取的可能。

(3) Secure 為 true 的 Cookie，無法透過 HTTP 協議傳輸到伺服器，只能透過 HTTPS 傳送。

![](https://img-blog.csdnimg.cn/img_convert/e108d9ad08a808182e69de5ce004133c.png)

淘寶伺服器頒發的 Cookie 裡，欄位 lid 儲存的是淘寶使用者名稱經過 URL encode 之後的值，dnk 存放的是淘寶使用者名稱的 Unicode：

![](https://img-blog.csdnimg.cn/img_convert/9d2fdad8660dddf44a572f6664a3b077.png)

![](https://img-blog.csdnimg.cn/img_convert/4a46663e1a055dd0539f02af862e2108.png)

有了本文的基礎，下一篇文章 Jerry 會介紹 SAP Commerce Cloud UI 的使用者會話管理，感謝閱讀。

從淘寶首頁登入說起

相關文章