是否值得开发一个需要使用asp.net配置文件系统进行用户身份验证的网站,还是更好地开发自己的SQL数据库等？我无论如何都不会避免使用SQL,即使我使用配置文件,我也会使用配置文件唯一ID来识别SQL表中的用户数据,因此从这个意义上讲,我不会完全避免使用SQL来获取用户信息. .
关于配置文件我最喜欢的是你可以使用它们在Web.config文件中创建自定义权限(),并避免在所有aspx源文件的顶部输入相同的代码来进行身份验证检查.
我喜欢它的另一件事是安全性内置了安全的身份验证cookie,因此我不必自己处理它们.
但这似乎并不是真的很重要.对于ASP.Net开发的内容以及它们旨在实现的目标,我只是感到困惑.
概要文件/成员资格和角色提供程序API非常相互交织,并且指定的内容非常狭窄.好处是你不需要做很多功能就可以了.缺点是当您需要的东西与提供的东西不匹配时.尽管如此,API还是有许多潜在的问题需要解决,使用它确实很有意义,至少对于身份验证而言.我的需求与API提供的不匹配,我真的只需要会员部分.问题是,我需要在Web应用程序和桌面应用程序中使用相同的身份验证和授权.我的需求非常独特,但它是专为课堂设置的.
让会员资格满足我的需求并不困难.我只需要实现Membership API.有些功能,我只是不需要使用会员资格API,如自我注册等.当然,这确实给我带来了角色管理的挑战.通常,只要您的用户对象实现IPrinciple,就可以直接使用它 – 但如果您的用户类未在同一程序集中定义,则开发Web服务器Visual Studio程序包会出现序列化问题.这些问题涉及序列化,您的选择包括将对象放在GAC中或使用GAC中的对象(如GenericPrincipal和GenericIdentity)自行处理跨appdomain序列化.后一种选择是我必须做的.
最重要的是,如果你不介意让API为你做所有的管理,那么它将工作得很好.这是一项聪明的工程工作,并试图迫使你走上一条具有良好安全实践的路线.我已经使用了许多不同的身份验证/授权API(大多数不是基于CLR的),并且API确实感觉有点限制.但是,如果您想避免会话/状态/缓存管理的陷阱,您确实需要使用API并根据需要插入您自己的提供程序.
使用您的数据库,如果您需要将用户链接到任何数据库元素,您将存储用户的登录ID(Context.User.Identity.Name).