ASP.NET 特定用户身份验证
让我描述一下我的情况:
我们正在开发一个创建网站的网络应用程序。
它创建的每个网站及其所有附加信息都保存在数据库中。
当客户端浏览这些网站之一时,他实际上正在浏览根应用程序,并且通过网站 ID,我们知道要以哪种布局向客户端发送哪些数据 - 但所有数据都来自主根 Web 应用程序。
我希望创建一个用户管理&该系统的身份验证,针对每个网站。
我的想法是:
在数据库 Users
表中创建一个包含 WebsiteID
列的表。
关于身份验证,我计划创建一些手动功能,在每个用户登录成功时,系统会在客户端计算机中创建一个带有 WebsiteId 的 cookie,以及一个随机 GUID,该 GUID 将保存在我们的数据库中以解决安全问题(如果有)没有 GUID,客户端可以使用 websiteId 手动创建 cookie 并破解系统)。
这就是我计划使用 HttpCookie 类执行此操作的方式:
// int websiteId -> the current website id.
// int userId -> the user id from the DB.
HttpCookie cookie = new HttpCookie("WebsiteAuthentication" + websiteId);
cookie.Values["WebsiteId"] = websiteId.ToString();
cookie.Values["UserId"] = userId.ToString();
cookie.Values["Guid"] = "SOME_RANDOM_GUID";
当我需要检查当前用户是否经过身份验证时,我将比较客户端 cookie(如果存在)以及 cookie 的 GUID 与保存在应用程序数据库中的 GUID。
这是解决我的问题的好方法吗?它是否受到足够的保护和安全?
我很高兴知道你对此有何评论,也许我完全偏离了方向......
希望我是可以理解的。谢谢大家,
加尔
Let me describe my situation:
We are developing a web application that creates websites.
Each website it creates is saved in the DB with all it's additional information.
When a client is browsing to one of these websites he's actually browsing the root application, and with the Website ID we know which data to send to the client in which layout- but all comes from the main root web application.
I wish to create a user management & authentication for this system, FOR EACH WEBSITE.
The idea I came with:
Create in the DB Users
table that will have a WebsiteID
column.
About the authentication, I planned to create some manual functions, that in each user login success, the system creates a cookie in the client's machine with the WebsiteId, and a random GUID that will be saved in our DB for safety issues (if there was no GUID, a client could manually create a cookie with the websiteId and hack out system).
This is how I planned doing it with the HttpCookie class:
// int websiteId -> the current website id.
// int userId -> the user id from the DB.
HttpCookie cookie = new HttpCookie("WebsiteAuthentication" + websiteId);
cookie.Values["WebsiteId"] = websiteId.ToString();
cookie.Values["UserId"] = userId.ToString();
cookie.Values["Guid"] = "SOME_RANDOM_GUID";
When I will need to check if the current user is authenticated, I will compare the clients cookie (if exists) and the cookie's GUID vs the GUID is saven in the applications' DB.
Is this a good way to solve my issue? Is it protected and safe enough?
I'll be happy to know what you say about it, maybe i'm totally off-course...
Hope I was understandable. Thanks all,
Gal
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我认为您应该使用会员提供商< /a> (如果需要,您可以创建自定义实现)。
您确实应该使用 FormsAuthentication.SetAuthCookie 来创建 cookie .
I think you should be using the Membership provider (you can create a custom implementation if you need).
You really should be using FormsAuthentication.SetAuthCookie for creating the cookie.
正如 CD 所说(我在评论中写道),您可以使用会员资格来获得您想要的东西。
但是您在应用程序 id 方面遇到了问题,因为 id 是在 web.config 中指定的,因此对于应用程序来说是全局的。这意味着您将无法直接处理不同的应用程序。
看来您可以从标准成员身份提供程序之一继承(SqlMembershipProvider 可能最接近您的需求),并且您可以从继承类中设置 ApplicationName。 但是您当然会遇到线程问题,除非您在设置应用程序名称后锁定整个语句,在这种情况下,您将会遇到性能问题。
另一方面,您可以获得数据库结构、存储为种子哈希的密码以及会员资格提供商提供的许多其他安全最佳实践,因此我仍然建议使用 SqlMembershipProvider;但是您可能需要进行一些更聪明的子类化,或者最终只是实现接口并使用组合来初始化每个子应用程序的成员资格提供程序,其中应用程序名称设置正确。
As CD says (and I wrote in my comment) you can use Membership to obtain what you want.
But you have a problem regarding the application id, since the id is specified in the web.config and thus global to the application. This means you will not directly be able to handle different applications.
It seems that you are able to inherit from one of the standard membership providers (the SqlMembershipProvider is probably closest to your needs), and from the ineheriting class you are able to set the ApplicationName. But you will of course get into troubles with threading unless you lock the entire statements after setting the applicationname in which case you will get into trouble with performance.
Un the other hand you get the database structure, passwords stored as seeded hashes and a bunch other security best practices given by the membership provider, so I would still recommend using the SqlMembershipProvider; but you might need to do some more clever subclassing or eventually just implement the interface and use composition to initialize a membership provider per sub application where the applicaiton name is set correctly.