什么是聯合登錄
因為公司產品的發展，會與第三方的一些商戶進行對接，商戶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，即執行聯合登錄的3、4步后（此時調用獨立代碼中調用商戶API獲取PartnerID的函數），則取出session中的回調地址（例子中的A）并進入
方案2：APP接口式
這個方案的通用代碼其實就是一個前端函數：
根據商戶調用其特定的獨立函數：前端能得到PartnerID，所以在需要登錄之前，先調用該商戶的獨立代碼中的調用nativeAPI獲取PartnerID的函數，得到PartnerID，再執行聯合登錄的3、4步，最后完成登錄操作。
方案3：憑證解密式
這個方案最簡單，只是在入口的路由加一個操作：
存儲加密憑證字符串：在入口路由上，將加密憑證存入session中，在需要登錄前，則調用該商戶的獨立代碼中的解密字符串得到PartnerID的函數，得到PartnerID，再執行聯合登錄的3、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，走正常的聯合登錄流程。
