2011-07-23 105 views
2

我們正在構建一個Web應用程序,現在我們正在決定如何跟蹤我們的用戶。我們的默認選項是維護我們自己的用戶註冊系統,這很令人頭疼(用戶名唯一性,註冊過程等)。依靠Facebook用戶標識作爲永久性用戶標識

作爲替代方案,我們可以使用人們的Facebook身份,這意味着他們將使用他們的Facebook電子郵件和密碼登錄到我們的系統。然後我們的後端將獲取用戶的Facebook ID(圖形ID),並將其存儲在數據庫中。任何用戶將更改/上傳到應用程序的數據都將鏈接到此ID。

現在的問題是,我們是否可以將ID作爲永久標識符,並在其周圍構建一個複雜的後端。我們如何確定Facebook不會更改某人的ID?

Azure Access Control等其他身份管理系統是否依賴此ID?

回答

4

Facebook的platform policy不鼓勵使用用戶標識符除了內部使用的任何東西。因此,如果您計劃擁有一個其網址類似/ users /的個人資料頁面,則可能違反了Facebook的隱私預期。您最好使用代理主鍵製作Users表格,並將他們的Facebook標識作爲非主要列。

此外,您可能會遇到用戶失去對其舊版Facebook帳戶的訪問權並希望將其網站上的帳戶與新的Facebook身份關聯的實例。如果您將自己的Facebook ID用作多個表中的外鍵,則您的應用程序數據會不必要地將舊的Facebook ID糾纏在一起。

+0

我沒有完全得到你所說的「用一個代理主鍵製作用戶表」。例如,你建議在我們的用戶表中,主鍵是一些生成的GUID,用戶,所以如果他的Facebook帳戶出現問題,他可以被識別出來?但是如果他忘記了GUID會怎麼樣? (我們不能發送給他一封電子郵件,因爲他沒有輸入郵件,如果他這麼做的話,它實際上是一個普通的用戶管理系統,而不是用戶名,你會得到一個生成的GUID –

+0

這是一個很好的觀點。支持我假設的情況下,用戶失去了訪問他們的Facebook帳戶,你將無法完全依靠Facebook身份驗證。 我只是想舉一個例子,其中一個用戶的Facebook ID可能因爲Facebook本身之外的原因而改變 – tuxedo25

+0

注意:當用戶通過Facebook進行身份驗證時,您可以請求獲得向他們發送電子郵件的權限。當然,您仍然可以允許他們設置除了facebook集成之外的常規用戶名和密碼,StackOverflow使用類似的模型。 – tuxedo25