问题:控制Session超时
我的会话每 20 分钟更新一次。我已将超时设置为 300 分钟,但它仍然会更新,可能是因为应用程序池会回收。
我正在存储 UserId,它是 Session 中的 Guid,它返回 null。问题是当我使用会员资格时
Membership.GetUser().ProviderUserKey
它工作正常。但显然它会调用数据库。我怎样才能防止这个问题的发生?为什么 Membership.GetUser().ProviderUserKey 成功而 Session 不成功?
My session renews every 20 minutes. I've set timeout to 300 minutes but still it renews probably because Application Pool recycles.
I am storing UserId which is Guid in Session which returns null. Problem is when I use Membership using
Membership.GetUser().ProviderUserKey
it works fine. But obviously it makes a database call. How can I prevent this problem from happening? Why does Membership.GetUser().ProviderUserKey succeeds whereas Session doesn't?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
为了完成 Jan 和 Neil 的答案,您应该查看您的web.config并设置两个超时(sessionState和身份验证< /em>)
会话状态超时指定会话在被放弃之前可以空闲的分钟数。默认值为 20。
表单超时用于指定表单身份验证会话的有限生命周期。默认值为 30 分钟。如果发出持久表单身份验证 cookie,则超时属性还用于设置持久 cookie 的生存期。
In order to complete Jan's and Neil's answers, you should look at your web.config and set both timeouts (sessionState and authentication)
Sessionstate timeout specifies the number of minutes a session can be idle before it is abandoned. The default is 20.
Forms timeout is used to specify a limited lifetime for the forms authentication session. The default value is 30 minutes. If a persistent forms authentication cookie is issued, the timeout attribute is also used to set the lifetime of the persistent cookie.
您的会话可能仍然有效(如果您将其设置为 300 分钟),但 ASP.NET 成员资格可能即将到期?
您是否也增加了身份验证超时?
Your session may still be alive (if you set it to 300 minutes) but the ASP.NET membership could be expiring?
Have you increased the authentication timeout too?
您正在混合身份验证和会话。这是两个完全不同的概念。
GetUser()
从您的 MemberShipProvider 返回当前经过身份验证的用户。会话和身份验证具有不同的超时 - 因此您的会话超时但用户仍然经过身份验证是有效的。
You are mixing authentication and session. These are two completely different concepts.
GetUser()
return the currently authenticated user form your MemberShipProvider.Session and authentication have different timeouts - so its valid that your session times out but the user is still authenticated.