DotNetNuke中Membership Provider機制

摘要：一直困擾於DotNetNuke眾為什麼Users表和Aspnet_Users之類的表沒有引用關聯性，最近在看《DotNetNuke 4進階編程》的時候終於明白了。

Users表是DotNetNuke自己的使用者表，而aspnet_之類的表asp.net 2.0的成員資格提供者(Membership provider)，這些表用於使用者驗證的，就像使用者的密碼就存在表aspnet_membership中，而且密碼是密文加密的。

下面是引用書中的一段內容。

為了實現成員資格提供者的全部好處，認可使用者資訊可以從DotNetNuke具體化，並且能夠存放在一個獨立於主要資料儲存的資料存放區中非常重要。例如，DotNetNuke可以使用Microsoft SQL Server作為它的資料庫來儲存內容和系統設定，但是成員資格提供者可以用Windows驗證、LDAP或者其他機制來處理驗證和授權。因為安全可以使用提供者模型具體化，所以確保成員資格提供者的實現沒有定製提供者使用的任何代碼或者資料庫表非常重要。成員資格提供者使用的資料表必須獨立於其他核心DotNetNuke表。DotNetNuke資料和成員資格提供者資料之間不能實施參考完整性(referential integrity)，而且不也不能使用串聯刪除(casecade delete)或者其他資料級同步方法。簡而言之，就是所有的秘密都發生在DotNetNuke的商務邏輯層。

在實現成員資格提供者過程中所面臨的挑戰之一，就是如何處理DotNetNuke內部支援、但成員資格提供者並不支援的欄位。理想情況下，解決方案應該將DotNetNuke中所有與驗證/授權相關的表徹底替換為成員資格提供者使用的表。但是無法實現這種解決方案，這是因為DotNetNuke中的驗證/授權表已經與應用程式中許多已有的和必需的特性綁定在一起。例如，DotNetNuke的Users表中有UserID列，用來為每個使用者儲存一個唯一的標識符。而UserID在幾乎所有的核心和第三方模組以及核心本身都大量使用。UserID的最大問題就是成員資格提供者中沒有這一欄位。相反，成員資格提供者使用了Useranme作為應用程式中使用者的唯一標識。這裡的挑戰就是DotNetNuke需要一種方式來維持UserID，從而保持依賴於UserID的DotNetNuke功能。這隻是一個由微軟公司提供的預設成員資格提供者不能處理的特性的例子。

最終，DotNetNuke需要維護一個附屬表來支援不能由成員資格提供者管理的DotNetNuke特性。這樣做的目的就是為了在DotNetNuke表中維護足夠的資訊，以使DotNetNuke的功能不會丟失，並且還可以分擔成員資格提供者表中的一些負擔。最終產生了一個與成員資格提供者中的表對應的資料模型，如圖所示。

 

注意，圖上面的表和下面的表沒有資料庫關係。他們之間的串連只是為了標識他們之間在理論上的關係，而不是在資料庫中的實際關係。

因為門戶網站、設定檔、使用者和角色的資料存放區在多個不相關的表中，所以由商務邏輯層負責聚集這些資料。例如，如果不收集aspnet_Users表（位於成員資格提供者中）和Users表（位於自身的DotNetNuke表中）中的資料，就無法得到一個完整的使用者表示。

除了聚集外，成員資格提供者使用的表中的資料必須與DotNetNuke自己提供的表中的資料自動同步。前面介紹過成員資格提供者支援眾多的資料存放區，而且在ASP.NET2.0中，這些資料存放區中的資料可以通過一個公用的應用程式配置工具 + 生產力管理。如果通過這個工具 + 生產力添加了一個使用者，那麼這個使用者沒有添加到DotNetNuke自己提供的表中。同樣，如果成員資格提供者使用了諸如LDAP的實現，那麼使用者將添加到LDAP中，而不是DotNetNuke自己提供的表中。這就是為什麼要在兩個資料結構之間提供同步服務的原因。因此如果手動添加一個使用者，需要是使用DotNetNuke內建的方法，如程式所示。

DotNetNuke.Entities.Users.UserController.CreateUser(oUserInfo)

DotNetNuke4.0完全利用了ASP.NET2.0成員資格提供者API的實現。應用程式的非典型特性在新的平台發布上構建，DotNetNuke4.0在ASP.NET2.0架構上提供了一個經過測試和證明的解決方案。這些特性示範了DotNetNuke安全架構的靈活性和可擴充性。