I am building an ASP.NET web site that uses FormsAuthentication and a standard Session mechanism with configuration like:
我正在构建一个ASP。使用FormsAuthentication和标准会话机制的网站，配置如下:
<authentication mode="Forms">
<forms cookieless="UseCookies" name=".MyAppAuth" loginUrl="~\Login.aspx" timeout="20"/>
</authentication>
...
<sessionState timeout="20" cookieless="UseCookies" />
It seems that the lifetime of an authentication cookie is not equal to the lifetime of the user Session. So ASP.NET doesn't guarantee that
似乎认证cookie的生命周期不等于用户会话的生命周期。所以ASP。净并不能保证
-
Session terminates when user logout,
当用户登出时，会话终止，
-
Session doesn't terminates before user logout.
会话不会在用户注销之前终止。
Is there a way to customize FormsAuthentication or\and the Session State mechanism to Reach these goals?
是否有一种方法可以定制FormsAuthentication或\以及会话状态机制来达到这些目标?
3 个解决方案
#1
6
There's no inbuilt mechanism because the reality is you want to keep users logged in for longer than you want to keep their sessions around for. Also, sessions are not meant to be guaranteed storage, and you should avoid any reliance on data being in session.
不存在内置机制，因为实际情况是你想让用户登录的时间比你想让他们的会话保持的时间长。此外，会话并不意味着可以保证存储，并且您应该避免任何依赖于会话中的数据。
Nothing happens on the server when an authentication cookie expires. There is no tracked state.
当身份验证cookie过期时，服务器上不会发生任何事情。没有跟踪状态。
You could have a 'logout' link and in the handler Abandon the session and SignOut from FormsAuthentication, but there's nothing that forces a user to log out from a website.
您可以有一个“注销”链接，在处理程序中放弃会话并退出FormsAuthentication，但是没有什么能强迫用户从网站上注销。
Some people like Session, however most hate or come to hate it because its use is abused. Main reasons are Session overuse tends to be the cause of poorly performing servers, and incorrect Session use can create websites that won't scale.
有些人喜欢会话，然而大多数人讨厌或讨厌它，因为它的使用被滥用。主要原因是会话过度使用往往是服务器性能差的原因，而不正确的会话使用可能会创建无法扩展的网站。
Avoid the use of Session if you can, and if you must use it, observe the recommendations in the MSDN article Improving ASP.NET Performance. Also have a look at Understanding session state modes + FAQ and in particular Q: Why isn't Session_End fired?
如果可以，避免使用会话，如果必须使用会话，请遵循MSDN改进ASP文章中的建议。网络的性能。还可以了解会话状态模式+ FAQ，特别是问:为什么Session_End没有被触发?
#2
9
I've heard this question many times, my answer is usually "why would you want this?". One does not require the other and their expiration times should be determined using different criteria.
我已经听过很多次这个问题了，我的回答通常是“你为什么想要这个?”一个不需要另一个，它们的过期时间应该使用不同的标准来确定。
Session state does not require a user to be logged in. An app doesn't even need to use authentication to use session state. You can have a web app where a user is already using session state even before logging in, and still using it after logging out. A "session" here is when a client (web browser) connects to a site, jumps around a few pages, and leaves. Whether a user is logged in or not is irrelevant. If you close your browser, open a new one, and go back to the site, a new session is created. But the server doesn't know you closed your old browser window, so the original session still exists. For scalability (mainly memory) purposes, we expire our sessions and free its memory and session-tracking resources. If a client takes too long to make a new request, the new request will create a new session.
会话状态不需要用户登录。应用程序甚至不需要使用身份验证来使用会话状态。您可以有一个web应用程序，用户在登录之前就已经在使用会话状态，在退出后仍然使用会话状态。这里的“会话”是指客户端(web浏览器)连接到一个站点，跳过几个页面，然后离开。用户是否登录无关紧要。如果您关闭浏览器，打开一个新的浏览器，返回站点，将创建一个新的会话。但是服务器不知道您关闭了旧的浏览器窗口，因此原始会话仍然存在。出于可伸缩性(主要是内存)目的，我们将会话过期并释放其内存和会话跟踪资源。如果客户端花了太长的时间来发出一个新的请求，新的请求将创建一个新的会话。
On the other hand, you can use authentication and not use session state at all. I usually start my apps with both session state and viewstate disabled and only enabled them if really needed and on a page-by-page basis (or control-by-control for viewstate).
另一方面，您可以使用身份验证，而完全不使用会话状态。我通常在启动应用程序时都禁用会话状态和viewstate，只有在真正需要的情况下才启用它们，并且是逐页的(或viewstate的逐个控件)。
Session expiration time should be determined by the memory used by each session, the memory available on the web server, number of concurrent users, and other scalability needs. It is usually in the range of a few minutes to an hour.
会话过期时间应该由每个会话使用的内存、web服务器上可用的内存、并发用户数量和其他可伸缩性需求决定。通常在几分钟到一小时之间。
Authentication is persisted as a cookie on the client and basically doesn't consume any resources the server. Scalability-wise, login expiration can usually be longer than session expiration. In fact a user can stay logged in indefinitely. When authentication expiration is kept shorter, it is usually for security reasons. You don't want your bank web site account to be available to someones else if you move away from your computer for 15 mins, right? You can log into gmail or facebook and select "remember me" and return a few days later and you are still logged in. But of course this would be a new session because no web app should hold on to session data for a few days.
身份验证作为cookie保存在客户机上，基本上不消耗服务器上的任何资源。在可伸缩性方面，登录过期通常比会话过期时间长。事实上，用户可以无限期地登录。当身份验证过期保持较短时，通常是出于安全原因。如果你离开你的电脑15分钟，你不希望你的银行网站账户对其他人开放，对吧?您可以登录gmail或facebook，选择“记住我”，并在几天后返回，您仍然登录。当然，这将是一个新的会话，因为任何web应用程序都不应该将会话数据保留几天。
Now, I've seen lots of people use the same length of time for authentication and session expiration. And many also Abandon() or Clear() their session when a user logs out. But they forget however that you still need to manage the case where the user is still logged in but the session has expired (which creates a new empty session on the next request), or when a user's authentication expired but not their session (requiring them to log in again, but carrying around an old un-expired session, possibly with another user's sensitive data). Taking care of these cases is very important, no matter what timeouts you ultimately choose for your application.
现在，我看到很多人使用相同的时间来进行身份验证和会话过期。当用户退出时，许多人也会放弃()或Clear()会话。但是他们忘记但是你仍然需要管理的情况下用户仍登录但会话已经过期(创建一个新的空会话在下一个请求),或者当一个用户的身份验证过期但不是他们的会话(要求他们再次登录,但是带着一个老出于会话,可能与另一个用户的敏感数据)。处理这些情况是非常重要的，无论您最终选择什么时间。
#3
4
The reason I sometimes ask myself this question, is to prevent accessing "expired" session objects. When the session expires prior to login expiration, and the user requests a page that uses data from the session, a nasty null reference exception happens.
我有时问自己这个问题的原因是为了防止访问“过期”的会话对象。当会话在登录过期之前过期，并且用户请求使用会话数据的页面时，就会发生一个讨厌的空引用异常。
You may find this article helpful. It discusses several solutions to detect expired sessions and inform the user about that.
你会发现这篇文章很有帮助。它讨论了几个解决方案来检测过期的会话并告知用户。
#1
6
There's no inbuilt mechanism because the reality is you want to keep users logged in for longer than you want to keep their sessions around for. Also, sessions are not meant to be guaranteed storage, and you should avoid any reliance on data being in session.
不存在内置机制，因为实际情况是你想让用户登录的时间比你想让他们的会话保持的时间长。此外，会话并不意味着可以保证存储，并且您应该避免任何依赖于会话中的数据。
Nothing happens on the server when an authentication cookie expires. There is no tracked state.
当身份验证cookie过期时，服务器上不会发生任何事情。没有跟踪状态。
You could have a 'logout' link and in the handler Abandon the session and SignOut from FormsAuthentication, but there's nothing that forces a user to log out from a website.
您可以有一个“注销”链接，在处理程序中放弃会话并退出FormsAuthentication，但是没有什么能强迫用户从网站上注销。
Some people like Session, however most hate or come to hate it because its use is abused. Main reasons are Session overuse tends to be the cause of poorly performing servers, and incorrect Session use can create websites that won't scale.
有些人喜欢会话，然而大多数人讨厌或讨厌它，因为它的使用被滥用。主要原因是会话过度使用往往是服务器性能差的原因，而不正确的会话使用可能会创建无法扩展的网站。
Avoid the use of Session if you can, and if you must use it, observe the recommendations in the MSDN article Improving ASP.NET Performance. Also have a look at Understanding session state modes + FAQ and in particular Q: Why isn't Session_End fired?
如果可以，避免使用会话，如果必须使用会话，请遵循MSDN改进ASP文章中的建议。网络的性能。还可以了解会话状态模式+ FAQ，特别是问:为什么Session_End没有被触发?
#2
9
I've heard this question many times, my answer is usually "why would you want this?". One does not require the other and their expiration times should be determined using different criteria.
我已经听过很多次这个问题了，我的回答通常是“你为什么想要这个?”一个不需要另一个，它们的过期时间应该使用不同的标准来确定。
Session state does not require a user to be logged in. An app doesn't even need to use authentication to use session state. You can have a web app where a user is already using session state even before logging in, and still using it after logging out. A "session" here is when a client (web browser) connects to a site, jumps around a few pages, and leaves. Whether a user is logged in or not is irrelevant. If you close your browser, open a new one, and go back to the site, a new session is created. But the server doesn't know you closed your old browser window, so the original session still exists. For scalability (mainly memory) purposes, we expire our sessions and free its memory and session-tracking resources. If a client takes too long to make a new request, the new request will create a new session.
会话状态不需要用户登录。应用程序甚至不需要使用身份验证来使用会话状态。您可以有一个web应用程序，用户在登录之前就已经在使用会话状态，在退出后仍然使用会话状态。这里的“会话”是指客户端(web浏览器)连接到一个站点，跳过几个页面，然后离开。用户是否登录无关紧要。如果您关闭浏览器，打开一个新的浏览器，返回站点，将创建一个新的会话。但是服务器不知道您关闭了旧的浏览器窗口，因此原始会话仍然存在。出于可伸缩性(主要是内存)目的，我们将会话过期并释放其内存和会话跟踪资源。如果客户端花了太长的时间来发出一个新的请求，新的请求将创建一个新的会话。
On the other hand, you can use authentication and not use session state at all. I usually start my apps with both session state and viewstate disabled and only enabled them if really needed and on a page-by-page basis (or control-by-control for viewstate).
另一方面，您可以使用身份验证，而完全不使用会话状态。我通常在启动应用程序时都禁用会话状态和viewstate，只有在真正需要的情况下才启用它们，并且是逐页的(或viewstate的逐个控件)。
Session expiration time should be determined by the memory used by each session, the memory available on the web server, number of concurrent users, and other scalability needs. It is usually in the range of a few minutes to an hour.
会话过期时间应该由每个会话使用的内存、web服务器上可用的内存、并发用户数量和其他可伸缩性需求决定。通常在几分钟到一小时之间。
Authentication is persisted as a cookie on the client and basically doesn't consume any resources the server. Scalability-wise, login expiration can usually be longer than session expiration. In fact a user can stay logged in indefinitely. When authentication expiration is kept shorter, it is usually for security reasons. You don't want your bank web site account to be available to someones else if you move away from your computer for 15 mins, right? You can log into gmail or facebook and select "remember me" and return a few days later and you are still logged in. But of course this would be a new session because no web app should hold on to session data for a few days.
身份验证作为cookie保存在客户机上，基本上不消耗服务器上的任何资源。在可伸缩性方面，登录过期通常比会话过期时间长。事实上，用户可以无限期地登录。当身份验证过期保持较短时，通常是出于安全原因。如果你离开你的电脑15分钟，你不希望你的银行网站账户对其他人开放，对吧?您可以登录gmail或facebook，选择“记住我”，并在几天后返回，您仍然登录。当然，这将是一个新的会话，因为任何web应用程序都不应该将会话数据保留几天。
Now, I've seen lots of people use the same length of time for authentication and session expiration. And many also Abandon() or Clear() their session when a user logs out. But they forget however that you still need to manage the case where the user is still logged in but the session has expired (which creates a new empty session on the next request), or when a user's authentication expired but not their session (requiring them to log in again, but carrying around an old un-expired session, possibly with another user's sensitive data). Taking care of these cases is very important, no matter what timeouts you ultimately choose for your application.
现在，我看到很多人使用相同的时间来进行身份验证和会话过期。当用户退出时，许多人也会放弃()或Clear()会话。但是他们忘记但是你仍然需要管理的情况下用户仍登录但会话已经过期(创建一个新的空会话在下一个请求),或者当一个用户的身份验证过期但不是他们的会话(要求他们再次登录,但是带着一个老出于会话,可能与另一个用户的敏感数据)。处理这些情况是非常重要的，无论您最终选择什么时间。
#3
4
The reason I sometimes ask myself this question, is to prevent accessing "expired" session objects. When the session expires prior to login expiration, and the user requests a page that uses data from the session, a nasty null reference exception happens.
我有时问自己这个问题的原因是为了防止访问“过期”的会话对象。当会话在登录过期之前过期，并且用户请求使用会话数据的页面时，就会发生一个讨厌的空引用异常。
You may find this article helpful. It discusses several solutions to detect expired sessions and inform the user about that.
你会发现这篇文章很有帮助。它讨论了几个解决方案来检测过期的会话并告知用户。