27

我目前正在轉換非常舊的,但工作的經典ASP網站ASP.Net。微軟會員供應商VS自定義提供者VS完成自定義登錄系統

它有一個完全自定義的書面用戶管理系統。雖然它工作正常,但它確實需要刷新,因爲我希望它能夠爲作品中的某些未來項目提供更多的靈活性。

當我問別人這件事時,他們說「你需要使用微軟的提供商」,並且講述了微軟如何免費發佈所有這些東西,它們有多好,應該儘可能多地使用。

我已經做了相當多的研究(主要看http://asp.net/learn上的視頻),並且對於一些功能留下了深刻的印象,因爲似乎有拖放組件的項目需要我花時間寫。

但是,當前的成員數據庫很難解釋,它是一個完全自定義的書面數據庫,它具有許多內部關係......它與默認的Microsoft提供程序並不真正「兼容」。

我看了一下How Do I: Create a Custom Membership Provider?,但是我感覺有點偏離了我的舒適區,擔心它會變慢,引入安全漏洞或根本無法工作。

在一天結束時,微軟成員資格提供商應該爲我工作 - 我真正需要的唯一定製是在我的數據庫中使用用戶名/密碼字段的登錄名以及具有很多定製的創建用戶腳本代碼到幾個第三方系統(需要提供服務等)。

我只是想知道,如果面臨類似的情況,你會怎麼做?

  1. 使用Microsoft成員資格提供並以某種方式得到它爲你工作(雖然我想建議)

  2. 使用Microsoft成員資格提供,但使用已在你的代碼定製的自定義提供。

  3. 使用您自己的完全定製的解決方案?

+0

如果所有用戶都在同一家公司,是否沒有其他身份驗證工具可以搭載?讓您的用戶不再追蹤另一個密碼,不用再寫密碼更改邏輯。 – DOK 2009-12-02 18:47:05

+0

並非所有的用戶都在同一家公司......第一個用戶註冊了一家公司,並從他們的控制面板,他們可以設置額外的用戶。 – Wil 2009-12-02 23:05:13

回答

8

該視頻不復雜的事情:)如果你要實現自定義的供應商,然後反射在現有的一個當然是一個良好的開端:)

作爲一個快速和骯髒的選項你可以, ,破解SQL成員資格提供程序使用的存儲過程,但提供服務的自定義代碼可能會擴展該過程。

如果您考慮一下,服務的遠程配置並不屬於成員資格提供者,它不是真正的成員資格功能 - 所有成員資格都提供用戶名和密碼以及身份驗證。我自己的感覺是,您應該將服務的提供從那裏移出,並在創建用戶後在ASP.NET網站上執行它 - 即使這只是在成員資格提供程序完成後才調用存儲過程。如果您這樣做,您可能會發現SQL成員資格提供程序將完成您需要的所有操作(可能還使用角色&配置文件提供程序),因此您的代碼編寫起來更少!

+0

我同意將它們分開...在寫它的時候,它只是一個單一的應用程序,並沒有構建模塊化,甚至認爲它將用於其他系統。這是我在刷新時想要做的事情之一。我會擔心編輯MS的存儲過程,稍後更新會使我困擾。在這一點上,我認爲我可以做所有的事情(在一天結束的時候,系統在過去的7年裏工作得很好),然後再看看MS的東西...... – Wil 2009-12-04 11:26:32

+0

但是,是的,角色而配置文件讓我驚歎不已,花了幾周的時間寫了一些東西,並且他們拖放了可以在盒子中運行的組件! – Wil 2009-12-04 11:27:14

+2

我還沒有看到視頻,但MSDN上的「如何實現自定義成員資格提供程序」(http://msdn.microsoft.com/en-us/library/ms366730.aspx)給出了一個很好的介紹一個簡單的成員資格提供者,包括可以很容易地適應數據庫實施的建議。 – 2009-12-04 12:05:15

3

如果現有提供程序工作正常(爲您的數據提供了正確的字段),請使用它開始。稍後您可以很容易地將其替換爲客戶提供商(僅配置一個值更改)。

請注意,這裏沒有「開箱即用」的ASP.NET管理界面,您需要自行打印或使用第三方界面。

8

我以前一直在類似的情況。在這兩種情況下,我們都圍繞現有機制創建了提供者的自定義實現(MembershipProvider,RoleProvider,ProfileProvider)。

在這兩種情況下,我們只使用提供者實現進行只讀訪問,例如,給我們在web.config等簡單驗證gubbins。用戶管理代碼保持良好,因爲它工作得很好。

+0

+1用於保持提供程序實現爲只讀。我也在項目上做了這些工作,以獲得圍繞表單身份驗證的內置功能的使用,同時將其餘的管理代碼留在單獨的類庫中。 – Element 2010-02-24 22:21:44

3

使用我專門的MembershipProvider來處理我自己的數據庫表。

相關問題