是否可以将 .ASPXAUTH 用于我自己的日志系统?
对于 Web 应用程序,我从使用 ASP.NET 会员资格切换到使用我自己的登录系统,该系统只是执行类似以下操作来将用户标记为已登录:
Session["UserId"] = User.Id
Is it possible to store the user id in the ASPXAUTH cookie, 捎带其加密,而不是使用标准会话?
目标是使登录状态持续的时间比会话更长,并且在浏览器和服务器重新启动后仍然存在。
For a web application I switched from using ASP.NET Membership to using my own log in system which just does something like this to mark a user as logged in:
Session["UserId"] = User.Id
Is it possible to store the user id in the ASPXAUTH cookie, piggybacking on its encryption, instead of using the standard session?
The goal is for the logged in state to last longer than a session and survive both browser and server restarts.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
更新:提供的原始答案是使用 MembershipProvider 的项目,并且在答案本身中进行了解释。我,提问者,没有使用它,所以我的问题的答案略有不同,但从这个答案中提取。我将我的答案放在底部,供任何关心的人使用,并逐字保留原始内容,因为它包含很多价值。
是的,您可以将 FormsAuthentication 用于您自己的策略。虽然 asp.net 数据库结构不适合您,但您可以提供 MembershipProvider 的简单实现以允许使用 Membership 基础结构。这两个功能并没有结合在一起,因此您可以决定哪个功能适合您。
请记住您的问题和一些评论,这里是一个可运行的示例,说明在不与默认实现和数据库模式结合的情况下利用提供程序模型是多么简单。
将表单身份验证用于您自己的目的很简单。您只需要提供身份验证并设置您自己的票证(cookie)。
使用自定义会员资格几乎同样简单。您可以根据需要实现尽可能少或尽可能多的提供程序,以支持您想要使用的 ASP.NET 基础结构功能。
例如,在下面的示例中,我展示了在登录过程中,您可以简单地处理登录控件上的事件来验证凭据并设置票证。完毕。
但我还将展示如何利用提供程序模型和实现自定义成员资格提供程序可以产生更强大、更简洁的代码。当我们在自定义成员资格提供程序中时,我实现了支持使用成员资格子系统所需的最低限度,以提供对用户元数据的轻松访问,而无需编写自己的基础结构。
只需将这些文件放入一个空项目中即可。
web.config
Site1.Master
Login.aspx
Default.aspx
CustomAuthClasses.cs
实际使用的解决方案(在使用 OpenID 的 ASP.NET MVC 项目中):
我有一个 AccountController,我用它来登录和注销用户,这些方法就在那里。
Update: The original answer provided was with a project using MembershipProvider and it's explained in the answer itself. I, the asker, am not using it, so the answer to my problem was slightly different but extracted from this answer. I'm putting my answer at the bottom for anyone that cares and leaving the original verbatim, as it contains a lot of value.
Yes, you can use FormsAuthentication for your own strategy. And while the asp.net db structure does not suit you, you may provide a simple implementation of MembershipProvider to allow use of the Membership infrastructure. These two functionalities are not married so you may decide what fits for you.
Keeping in mind your question and some of the comments, here is a runnable example of how simple it is to leverage the provider model without being married to the default implementations and db schemas.
Using forms auth for your own purposes is simple. You just need to provide authentication and set your own ticket (cookie).
Using custom membership is almost as simple. You can implement as little or as much of the provider as you need to support the asp.net infrastructure features that you would like to employ.
e.g. in the sample below, I show that in the login process you may simply handle an event on the login control to validate credentials and the set the ticket. Done.
But I will also show how leveraging the provider model and implementing a custom membership provider can result in stronger, cleaner code. While we are in the custom membership provider I implement the minimum necessary to support using the Membership subsystem to provide easy access to a user's meta data without the need to write your own infrastructure.
Just drop these files into an empty project.
web.config
Site1.Master
Login.aspx
Default.aspx
CustomAuthClasses.cs
Solution actually used (in as ASP.NET MVC project using OpenID):
I have an AccountController which I use to log users in and out and these methods are there.
ASPXAUTH cookie 将身份验证令牌与会话完全分开,这是使用它的原因之一。如果您的系统使用会话,那么它与表单身份验证尝试执行的操作确实不一致。
如果一切都在会话中,那么假设会话是安全的,那么实际上您根本不需要身份验证票证。
The ASPXAUTH cookie separates the authentication token from the session entirely, it's one of the reasons it's used. If your system uses session then it's really at odds with what forms authentication is trying to do.
If everything is in a session then really you don't need the authentication ticket at all, assuming the session is secured.