我有一个使用表单身份验证的 Asp Mvc 2 站点。当我在本地运行它时,我可以登录并无限期地保持登录状态。
然而,当我把它放在服务器上时,我似乎只保持登录状态几分钟,然后似乎就被注销了。我查看了 cookie,有 2 个似乎相关:
.ASPXAUTH 这是一个会话 cookie
.ASPXANONYMOUS 将于 3 个月后到期。
当我刷新页面时,cookie 保持不变,直到我注销,此时我似乎获得了新的 .ASPXANONYMOUS cookie,但 .ASPXAUTH 似乎是相同的。
看来我可以保持登录状态,直到我在一段时间后做某事。如果我登录后立即提交表单,那么它可以正常工作,但是如果我继续一次又一次地提交数据,然后在一分钟左右后,其中一次提交将以注销用户的身份进行,而不是以注销的用户的身份进行。已登录,所有其他提交都是如此。
可能会导致此行为的原因是什么以及我如何找出不同之处&更改它以便我可以无限期地保持登录状态?
编辑,
它是一台服务器,但经过更多调查和搜索后,可能的候选者似乎是我在服务器上使用了超过 100mb,并且应用程序池正在被回收。我想现在我需要知道
- 如何检查我正在使用多少内存。
- 有什么建议可以减少这种情况。
I have a Asp Mvc 2 site using forms authentication. When I run it locally I can log in and stay logged in indefinitely.
However when I put it on the server I seem to only stay logged in for a few minutes and then seems to be logged out. I have looked at the cookies and there are 2 which seem relevant:
.ASPXAUTH which is a session cookie
.ASPXANONYMOUS which expires in 3 months.
When I refresh the page the cookies stay the same until I get logged out, when I seem to get a new .ASPXANONYMOUS cookie, but the .ASPXAUTH seems to be the same.
It seems that I might be able to stay logged in until I do something after a certain amount of time. If I submit a form as soon as I am logged in then it works ok, but if I keep submitting data again and again then after a minute or so, one of the submits will happen as a logged out user and not as the user who was logged in, which all the other submits worked as.
What might cause this behaviour and how can I track down what is different & change it so that I can stay logged in indefinitely?
EDIT,
its a single server, but after some more investigation and searching the likely candidate seems to be that I am using more than 100mb on the server and the application pool is getting recycled. I suppose now i need to know
- How can I check how much memory I'm using.
- What advice there is to reduce that.
发布评论
评论(5)
ASP.NET 应用程序是否正在重新循环或关闭(例如,由于空闲超时或新建/更改的程序集)?
当 ASP.NET Web 应用程序启动时,默认情况下,它将生成视图状态和会话 cookie 的加密密钥。这将使最初从应用程序的早期运行(或从不同的系统)提供的任何此类数据无效。
要使会话在 ASP.NET 应用程序周期(和多服务器场)中生存,您可以在
web.config
中指定密钥:其中
decryptionKey
和validationKey 是长度取决于算法的十六进制字符串(AES:64 位和 SHA1:128,对于其他算法,请检查 MSDN)。
这些密钥应该以加密方式生成,.NET 具有可以从 PowerShell 使用的类型来执行此操作:
对于 AES,使用上述数组长度,对于 SHA1,使用长度 64。
Could it be that the ASP.NET application is being re-cycled or shutdown (e.g. due to idle timeout, or newly built/changed assemblies)?
When an ASP.NET web application starts up it will, by default, generate encryption keys for view state and session cookies. This will invalidate any such data originally served from an earlier run of the application (or from a different system).
To have sessions survive ASP.NET application cycles (and multi-server farms) you can specify the keys in your
web.config
:where
decryptionKey
andvalidationKey
are hex strings of length depending on the algorithm (with AES: 64 digits and SHA1: 128, for other algorithms check MSDN).These keys should be cryptographically generated, and .NET has the types to do this which can be used from PowerShell:
For AES use the above array length, for SHA1 use a length of 64.
Web 服务器上的会话超时配置的时间跨度很可能比您在 web.config 中的表单身份验证配置中设置的时间跨度小得多。
IIS6 和 IIS7 的默认会话超时为 20 分钟。
如果您有权访问 Web 服务器的管理界面,则可以通过 GUI 提高超时,但如果您的 IIS7 使用
和,也可以从配置文件中设置超时
部分:http ://msdn.microsoft.com/en-us/library/cc725820(v=ws.10).aspx
It is quite likely that Session Timeout on the web server is configured to a much smaller timespan than you have set in your Form Authentication configuration in web.config.
The default Session Timeout is 20 minutes for IIS6 and IIS7.
If you have access to the web server's admin interface, you can raise the timeout via the GUI, but it can also be set from the config file if your IIS7 using the
<sessionState>
and<sessionPageState>
sections:http://msdn.microsoft.com/en-us/library/cc725820(v=ws.10).aspx
检查 webconfig 身份验证部分
确保每个托管站点的身份验证 cookie 名称是唯一的。
Check the webconfig authentication section
Ensure that the authentication cookie name for each hosted site is unique.
来到这里遇到了类似的问题,按照@Richard的建议,我查看了应用程序池的回收设置。我发现设置已更改,
定期时间间隔(以分钟为单位)
值设置为 1 分钟。这意味着应用程序池每分钟都会被回收。要更改此设置,请右键单击应用程序池,选择
回收
选项,更改定期时间间隔(以分钟为单位)
下的值。我将其设置为与其他应用程序池使用的值相同。此更改解决了该问题,事实证明,不久前在使用过期的 SSL 证书进行一些误导性故障排除期间,该值被设置为较低的值。
Came here with a similar issue, following the suggestion by @Richard, I looked at the Application Pools' recycling settings. What I found was the settings were changed and the
Regular time intervals (in minutes)
value was set to 1 minute. This meant that the app pool was being recycled each minute.To change that, Right-click on the application pool, select the
Recycling
option, change the value underRegular time intervals (in minutes)
. I set it to the same value as the other Application Pools were using.This change fixed the issue, turns out it was set to a low value a while back while during some misguided troubleshooting with an expired SSL certificate.
如果这些都不起作用,请检查应用程序池并确保空闲超时设置为 20 分钟以上。单击应用程序池,选择右侧的
高级设置
链接,找到进程模型
部分,然后增加其中的空闲超时
值。If none of these work, check in the Application Pools and ensure that the Idle Timeout is set to 20+ minutes. Click on the application pool, select the
Advanced Settings
link to the right, find theProcess Model
section, and increase theIdle Timeout
value there.