【问题标题】:Sessionstate timeout, Auth timeout, App pool idle, and server session state会话状态超时、身份验证超时、应用程序池空闲和服务器会话状态
【发布时间】:2014-11-20 11:30:50
【问题描述】:

从我的配置中设置我的表单身份验证超时和 sessionState 超时似乎从来没有达到预期的效果。我总是必须在服务器上的网站上设置会话状态超时,而且我似乎也需要设置应用程序池空闲超时。

如果服务器可以直接覆盖,那么配置设置的意义何在?

设置的优先级是什么,严格来说是身份验证和保持用户登录的时间?我没有对此进行广泛的测试,但感觉如果这 4 个设置中的任何一个不同步,用户就不会按预期超时。

【问题讨论】:

    标签: asp.net iis timeout session-timeout


    【解决方案1】:

    主要的是它们根本不相关。 表单身份验证超时与会话超时没有任何关系。表单身份验证超时可能会滑动也可能不会滑动,并且仅存储身份验证 cookie。即使它们被设置为滑动,用户仍然必须在超时的中点之后与服务器交互才能滑动,否则它不会。

    如果需要,会话超时只是为了将数据存储 X 时间,并且超时会滑动。

    应用程序池可确保一切顺利运行。应用程序池需要经常回收,这可能会造成破坏,但这是应用程序的健康状况以及它们所担心的服务器。当然,如果您不使用状态服务器或将会话存储在数据库中,会话可能会结束up也被杀了。

    在这种情况下有一些帮助的事情: 明智地使用会话,因为它是资源的猪,并且总是有办法检查空值并在它为空时重新创建所需的对象/值。 为您的应用创建机器密钥。这将确保应用程序加密数据的方式不会随着每次应用程序回收而改变。如果发生回收,它可能会对登录用户产生影响,因为票证的加密可能不匹配。如果需要,创建显式机器密钥的一个很好的副作用也可以帮助您使用网络花园,但前提是您将状态服务器或存储会话存储在数据库中,因为内存中的会话不能在进程之间共享。

    因此它们不是相互关联的,而是可以相互影响。我也不希望应用程序拥有自己的设置来覆盖应用程序池设置,因为设置良好的应用程序池可以使站点和服务器保持健康并运行良好,这是它胜过一切的主要原因。

    【讨论】:

      猜你喜欢
      • 2012-02-17
      • 1970-01-01
      • 2013-02-17
      • 1970-01-01
      • 2011-10-11
      • 2018-07-03
      • 1970-01-01
      • 2018-09-24
      相关资源
      最近更新 更多