值得使用ASP.Net內置配置文件系統嗎？

Question

我剛剛發現ASP.net使用自己的配置文件系統來註冊用戶，並且似乎有很多可用的特性（如安全認證）。然而，對於通用開發環境而言，具有這樣的功能似乎相當具體，而在配置文件系統的背景下工作的東西卻沒有真正知道如何（像存儲用戶數據的地方）那樣讓我害怕。

是否值得開發一個網站，使用asp.net配置文件系統，需要用戶認證，或者會更好地發展自己的使用SQL數據庫等？即使我使用配置文件，我也不會避免使用SQL，我將使用配置文件唯一標識來標識SQL表中的用戶數據，所以從這個意義上說，我不會避免使用SQL來完成用戶信息。

我最喜歡關於配置文件的事情是，您可以使用它們（）在Web.config文件中創建自定義權限，並避免必須在所有aspx源文件的頂部鍵入相同的代碼來執行身份驗證檢查。

其他的事情，我挺喜歡它是安全性是建立在安全的身份驗證Cookie，所以我不會有對付他們自己。

但它似乎並不像是什麼大不了的事真。對於配置文件在ASP.Net開發中所處的位置以及它們旨在實現的目標，我只是感到困惑。

Answer 1

的資料/成員資格和角色提供API非常交織在一起，並指定東西很狹窄，我會用它。好處是，你不得不做很多功能的工作。缺點是當你需要什麼不符合提供的。儘管如此，API還是有很多潛在的障礙，至少對於身份驗證來說，使用它確實是有意義的。

我的需求與API提供的不匹配，我真的只需要Membership部分。問題是我有一塊需要在Web應用程序和桌面應用程序中使用相同的身份驗證和授權。我的需求非常獨特，但它是爲課堂設置而設計的。

獲得會員資格以滿足我的需求並不困難。我只需要實現Membership API。有些功能我不需要使用Membership API，比如自我註冊等。當然這給我帶來了角色管理的挑戰。通常情況下，只要用戶對象實現了IPrinciple，它就可以直接使用 - 但是如果您的用戶類沒有在同一個程序集中定義，那麼開發Web服務器Visual Studio包會出現序列化問題。這些問題涉及序列化，您的選擇包括將對象放入GAC中，或者使用GAC中的對象（如GenericPrincipal和GenericIdentity）自己處理跨應用程序域序列化。後一種選擇是我必須做的。

底線是，如果你不介意讓API完成所有的管理你的，比它會工作得很好。這是一個聰明的工程工作，並試圖強制你採用體面的安全措施。我已經使用了許多不同的認證/授權API（大多數不是基於CLR的），並且API確實感覺有點受限。但是，如果您想通過會話/狀態/緩存管理避免陷阱，那麼您確實需要使用該API並根據需要插入自己的提供程序。

與您的數據庫，如果你需要用戶與你會存儲用戶的登錄ID（Context.User.Identity.Name）的任何數據庫元素聯繫起來。

Answer 2

您似乎混合配置文件/成員資格/角色提供程序API。但要回答你的問題：爲什麼不使用它？除非有真正的約束，使得它無法使用...