論H5嵌入APP的聯合登陸的解決方案

都是本人理解，筆記大體概念，不詳細也並不是徹底正確，因此僅供參考。

---

什麼是聯合登陸

由於公司產品的發展，會與第三方的一些商戶進行對接，商戶APP提供入口，進入咱們的H5頁，從而提供服務。

而商戶但願用戶在其APP進行帳戶登陸後，進入H5頁再也不進行登陸，因此咱們的H5須要拿到用戶在商戶的帳戶的標識id（暫時稱之PartnerID），而後與咱們的產品的帳戶標識id（暫時稱之H5ID）進行一個關聯，這樣在用戶登陸APP後，咱們可以經過PartnerID去查詢關聯的H5ID以獲取帳戶信息，這樣就能夠保持登陸的同步了。

---

解決方案

上述描述中的一個關鍵點是：如何拿到PartnerID

獲取PartnerID大致有以三種方案：

• 方案1：受權回調式，商戶提供受權頁面，H5頁面須要登陸時，先進入商戶提供的受權頁，由用戶贊成受權，進而獲取PartnerID
• 方案2：APP接口式，商戶APP存在nativeAPI，H5頁面調用nativeAPI以獲取PartnerID
• 方案3：憑證解密式，商戶APP在H5的url的query上添加加密字符串，H5頁面取之解密後獲取PartnerID

基本說遇到的聯合登陸大多以上三種之一，例如微信受權登陸，能夠視微信爲商戶，微信的unionid即PartnerID，微信使用的就是方案1。

另外實方案1是方案2的一個完善，商戶提供的受權頁上其實使用了方案2來獲取PartnerID，這樣能夠保證本身APP的nativeAPI是由本身的H5頁所調用，進而增長安全性。

因此說，就安全性的排序爲：1 > 2 > 3

越安全開發即越複雜，因此，開發的複雜度也就是以上的排序。

---

聯合登陸的詳細步驟

代碼就不貼了，詳細步驟以下：

• 1：準備進入一個H5頁面，它須要登陸方可訪問
• 2：在進入以前先取PartnerID，商戶APP未登陸則進行APP登陸，再返回PartnerID
• 3：獲得PartnerID，去查詢相應的H5ID，有則存儲帳戶登陸信息進入第5步，無關聯則進入下一步
• 4：H5登陸頁進行登陸，登陸後獲得H5ID，將H5ID與PartnerID進行綁定，而且存儲帳戶登陸信息
• 5：此時已登陸，進入頁面中

獨立代碼

方案有三種，但有些代碼是必須得寫的，總結以下：

• 配置文件：由於商戶不一樣，則接入類型和配置參數不一樣，假設有一個 shanghu.js ，以下代碼：

module.exports = {
  id: 'a', // 商戶名稱
  type: 1, // 接入方案類型
}
複製代碼

• 方案1：「調用進入商戶受權頁」和「調用商戶API獲取PartnerID」的兩個函數
• 方案2：「調用nativeAPI獲取PartnerID」的函數
• 方案3：「解密字符串獲得PartnerID」的函數

這些根據商戶不一樣代碼也是不一樣的，作不到統一解決方案，so，老老實實寫吧。

不過有些代碼能夠作成通用的，開發完成則後續接入能夠不用再管了。

通用代碼

方案1：受權回調式

說是最複雜的方案，其實通用代碼就兩個路由：

前往受權 /toAuth：前往須要登陸的頁面時（假設地址爲A），則先前往此路由，此路由接收一個回調地址（A）並存儲在 session 中，而後此路由進入商戶受權頁（此時調用獨立代碼中進入商戶受權頁的函數）

受權回調 /authBack：必須提供給商戶的回調路由，當商戶受權頁面中用戶受權後，會返回此路由，用戶的token亦會在query上傳遞回來，經過token去換取PartnerID，即執行聯合登陸的三、4步後（此時調用獨立代碼中調用商戶API獲取PartnerID的函數），則取出session中的回調地址（例子中的A）並進入

方案2：APP接口式

這個方案的通用代碼其實就是一個前端函數：

根據商戶調用其特定的獨立函數：前端能獲得PartnerID，因此在須要登陸以前，先調用該商戶的獨立代碼中的調用nativeAPI獲取PartnerID的函數，獲得PartnerID，再執行聯合登陸的三、4步，最後完成登陸操做。

方案3：憑證解密式

這個方案最簡單，只是在入口的路由加一個操做：

存儲加密憑證字符串：在入口路由上，將加密憑證存入session中，在須要登陸前，則調用該商戶的獨立代碼中的解密字符串獲得PartnerID的函數，獲得PartnerID，再執行聯合登陸的三、4步，最後完成登陸操做。

查詢接口

聯合登陸的第3步中，會存在兩個api，這些由咱們本身開發，分別是：

• 查詢綁定帳戶：經過PartnerID查詢關聯的H5ID，若存在，則返回帳戶的登陸信息，若不存在，則返回無綁定關係，前端根據api結果判斷是否進入H5的登陸頁
• 進行帳戶綁定：將PartnerID和H5ID進行綁定，返回帳戶的登陸信息

---

其餘比較特殊的登陸

靜默登陸

在上面的過程當中，中間會有一層綁定的操做，此時須要內部H5頁進行一次登陸，而這樣會出現兩次登陸的狀況：APP登陸後，首次進入H5，H5中登陸並綁定。

因此，有些商戶有這樣的需求：APP已登陸，則在H5內部無需登陸，即首次進入H5也無需在H5進行登陸綁定就能夠有登陸狀態。

這種樣的解決方案其實很簡單，在查詢的兩個接口中，存在查詢綁定帳戶的接口，這個接口的功能是：

• 經過PartnerID查詢關聯的H5ID，若存在，則返回帳戶的登陸信息，若不存在，則返回無綁定關係，進入H5的登陸頁

若是須要知足上述需求，實際是這個接口永遠返回登陸信息，包括首次登陸，如此簡單便可。

由於在調用接口時，會傳遞商戶名稱和PartnerID，接口開發人員能夠根據商戶名進行操做。

例如：平臺cmb須要靜默登陸，則後端開發人員在查詢綁定帳戶接口接收參數 partnerName，若 partnerName === 'cmb'，則靜默註冊一個帳號並登陸，返回登陸信息，其他的則正常流程。

而對於多個商戶都有此類需求，能夠維護一個 array ，符合array內的條目，進行進行靜默註冊並登陸，不符合則走正常的步驟。

快應用的嵌入

快應用頁能夠獲取用戶在開放平臺unionid，在進行嵌入開發時，有時候須要拿到unionid和H5的帳戶進行綁定。

首先，快應用提供了API以獲取用戶惟一身份標識，其次，快應用自己應該視爲一個輕量APP的開發，而快應用也提供了一些方法，咱們能夠封存一些方法和接口，由H5以nativeAPI的方式進行調用和開發，故而快應用的聯合登陸應該是方案2：APP接口式。

封裝

web組件可使用：

• postMessage：向內部H5推送一個消息
• onmessage：監聽內部H5的消息

內部H5可使用：

• system.postMessage：向外部web組件推送一個消息
• system.onmessage：監聽外部web組件傳遞的消息

故能夠在web組件監聽 onmessage ，獲得網頁 system.postMessage 發送的登陸請求時，在快應用層去調用登陸API，獲得PartnerID後，再由web組件的 postMessage 將PartnerID傳遞給內部H5頁面，而H5則獲得PartnerID，走正常的聯合登陸流程。

---

END

我的特別不建議針對一個商戶就寫一套方案，浪費時間且大量重複代碼，不利於代碼維護。

雖然說有多種狀況，但大部分都是能夠圍繞三種方案進行延伸拓展，有其餘狀況再補充，如今就寫到這裏。。