ASP.NET成員資格：是或不是？

Question

我正在考慮如何實現ASP.NET和MVC2的授權和身份驗證。讓我們把它稱爲用戶系統。

我已經在野外看到三種解決方案：

• 使用內置的ASP.NET成員資格系統（NerdDinner）
• 推出自己的（Shrinkr）
• 創建一個抽象層對於ASP.NET成員資格（Tekpub's mvcstarter kit）

我一直在閱讀你的認識思想，很多人說試圖推出自己的「用戶系統如果你對安全細節沒有注意，可能會更危險。另一方面，解決方案更簡單一些。一切都可能存儲在一個數據庫中，用戶特定的東西在一個用戶表中。這個解決方案的開銷似乎很低。

使用ASP.NET成員資格解決方案允許使用很多開箱即用的功能，但恕我直言，真的是混淆。您可能需要將會員資料存儲在自己的數據庫中，並以某種方式將用戶實體從您的網站特定數據庫鏈接到ASP.NET。

如果您使用的是ASP.NET成員

• 請問你的數據庫架構是什麼樣子？如何創建與ASP.NET會員用戶的外部關係（即歌曲< => FavoriteSongs（< => SiteUsers）< => aspnet_Users）？
• 你爲什麼不推出自己的？

如果您已經推出自己的

• 什麼樣的用戶系統抽象層，如果有的話，你有沒有用？
• 你爲什麼不使用ASP.NET成員資格？

我真的被分析這些可能性癱瘓。請從這個粘滯的會員癱瘓網絡向正確的方向發展！謝謝。

Answer 1

內置的會員提供商已經安全，真的很容易使用。幾個小時後，您就可以開始使用內置會員了。另外（取決於你正在構建什麼類型的應用程序），你也可以使用StackOverflow使用的OpenID來檢出。

此外，使用內置的成員資格提供程序，創建關係與使用「uniqueidentifier」將aspnet_User表（我無法記住頭頂上的確切名稱）與相關表關聯一樣簡單。

我把我的所有會員「東西」存儲在與系統數據庫相同的數據庫中，它從來沒有讓我誤導我。創建會員「東西」也很容易。針對數據庫運行aspnet_regsql.exe，您希望擁有asp.net成員資格

Here's another SO question沿着相同的行。

Answer 2

很多人選擇不出於自己的理由推出自己的認證系統！這是相當危險的，並且有很多小的方法可以使錯誤發生並讓您的站點面臨攻擊。

然而，我是那些冒險者之一，並且確實推出了自己的產品。我加倍和三重檢查了每一行代碼中的安全漏洞，到目前爲止，自從我發佈1.0認證系統以來，我沒有任何安全缺陷修補。無論如何，我的身份驗證系統被命名爲FSCAuth和BSD許可。

• 什麼樣的用戶系統抽象層，如果有的話，你使用？

我不太清楚你的意思。我基本上有一個層，其中檢索用戶數據並將其寫入/從數據庫寫入。 FSCAuth實際處理cookies和HTTP認證的一層。而且，您告訴FSCAuth的一個圖層是「只有當前用戶在Admin組中時才能看到此頁面」。

我的UserData類很簡單，只需要4個字段：Username，PasswordHash，UniqueID和Salt。這是FSCAuth所依賴的。如果你需要更多的字段，你可以繼承UserData類的形式，它的工作原理是一樣的。

• 你爲什麼不使用ASP.NET成員資格？

我發現這麼多的短缺憾在內置在ASP.Net認證

1. ，如果你想使用內置的成員資格提供
2. 有時其他任何大量的代碼必須被寫入你必須自己處理cookie，我會說這是危險的
3. 幾乎不可能使用Blowfish散列算法
4. 爲每個頁面加載多次往返數據庫
5. 有狀態會話（用戶登錄時，將記錄放入數據庫中）使其更難以擴展到多個服務器，並且通常會給數據庫服務器帶來更多不必要的壓力。
6. 細粒度的認證（可以看到人A的電子郵件，但沒有人B的）是比較困難的，比我想
7. 的GUID

許多問題是由設計，我相信是的症狀試圖製作一個滿足每個人的軟件。

那麼，在FSCAuth中，我通過設計留下了很多東西，老實說，它不適合所有人......但在許多常見場景中使用ASP.Net成員資格要容易得多。可以在陽光下使用任何散列算法。單個數據庫命中認證。無狀態登錄。唯一的ID可以是適合字符串的任何內容。等等

因此，如果您在圍繞ASP.Net的內置身份驗證和自行滾動之間做出決定，請首先給FSCAuth一看。如果沒有其他的東西，它會成爲一個很好的起點。