綁定 域名 main win 子頁面 一件事 deb 產生 父窗口

一、需求：

facebook、naver、kakao在登錄註冊浮層的第三方登錄需求，要求用戶在第三方登錄流程中不能中斷浮層，即：用戶在online登錄註冊浮層中發起第三方登錄時，浮層不能被關閉或者刷新，只能通過將第三方登錄的信息會傳到過來後，進入下一個流程。

二、第三方登錄的流程：

用戶在我們的登錄註冊浮層中發起第三方登錄——>打開第三方登錄頁面——>第三方登錄成功後，將信息回傳到浮層，然後走接下來的流程。

三、第三方登錄碰到的問題及解決：

【一】第三方平臺給開發者造成的局限性: 1）為了安全，只有在第三方接入平臺註冊過的頁面才可以拿到第三方登錄成功後的信息，另外第三方平臺提供給開發者接入的方式不盡相同，比如 facebook比較友好，一個第三方平臺開發者帳號能夠註冊不限個數的登錄成功後的回調頁面，而像kakao、naver就相當不友好了，不提供英文文檔是一方面，kakao可以註冊多個domain，但只能制定一個path，naver可以註冊5個頁面。那問題來了，當一個公司有多個應用多條產線都想接入該第三方平臺，如果一個開發者帳號只能配置有限個頁面肯定是行不通的。那就申請多個開發者帳號嘍，但是可能會出現這種現象：一個用戶在我們公司產品A上做了第三方登錄，如果用戶之前沒有應用帳號，我們給他創建了一個，同樣是這個用戶在我們公司產品B上做了第三方登錄，我們又給他創建了一個應用帳號。同一個用戶同一個第三方帳號登錄兩遍我們都給他創建了兩個帳號。這種現象會由什麽原因產生呢？——這兩個第三方入口來自兩個獨立的第三方開發者賬戶。解決方法有兩個：

• 允許多個開發者帳號，各個產線可以各自接入，後端進行所有信息的統一。
• 只有一個開發者帳號，大夥都公用頁面吧，反正註冊頁面也就只做一件事，就是把第三方登錄信息拿到，然後傳到自己的頁面。

最後選擇的方案是2——公用頁面。kakao這類的，雖然只有限制的註冊，但它還是分了 android ios restfulapi三種接入入口。 2）調試困難。facebook可以批量生產測試帳號，但測試帳號只能做直接登錄，對於是否有我們平臺帳號需要綁定的case無法覆蓋到，kakao naver就只能手工註冊帳號進行測試。幸好有我們應用的FAT環境，可以在FAT環境裏頭隨意註銷帳號隨意生成帳號。 3）debug過程很困難。因為第三方登錄是在第三方完成的，中間過程很難控制和復現，另外如果拿到的登錄信息已經使用，比如拿這個登錄信息做了我們應用中某個接口請求，那這個登錄信息就不能做二次使用去復現問題。所以有關這塊的話只能依靠編碼人員，自己用fiddle做好相關頁面的自測，不然直接接入第三方後再測，解決bug的代價會成倍上升。

【二】開發技術難點

1）保證浮層不被關閉，不被刷新，第三方登錄頁面你如何打開：首次打開采用_blank，之後redirect使用_self方式打開頁面。 2）頁面通信，如果將登錄信息進行回傳，通過父窗口open在第三方註冊過的頁面，通過註冊過的頁面打開第三方登錄頁面，第三方登錄成功後它自己會進行一次redirect，redirect到註冊過的頁面，此時拿到url中的登錄信息，進行回傳，回傳方式就是子頁面通過window.opener調用父頁面的js方法。 3）浮層可能在各種產品產線中使用，如何父子頁面js跨域問題。iframe + window.name是一個可行但是繁瑣的方案。具體情況可以解決，可以通過配置多域名站點進行跨域，即在浮層打開第三方註冊過的頁面的時候，將當前domain帶上，當完成登錄進行回傳登錄信息的時候再做一次多域名站點的跳轉，跳轉到domain下的站點，然後再在該站點下進行回傳。只要把在第三方註冊過的頁面配置成多域名站點即可。

總結：接入第三方平臺登錄註冊項目