7

我收到来自我的用户的报告和投诉，他们将使用屏幕并在下一次请求时立即被踢回登录屏幕。它不会一直发生，而是随机发生。查看 Web 服务器后，应用程序事件日志中显示的错误是：

事件代码：4005 事件消息：请求的表单身份验证失败。原因：提供的票已过期。

我阅读的所有内容都是从人们询问网络花园或负载平衡开始的。我们没有使用其中任何一个。我们是带有 IIS6 的单一 Windows 2003（32 位操作系统，64 位硬件）服务器。这也是该服务器上唯一的网站。

此行为不会对用户产生任何应用程序异常或可见问题。他们只是被引导回到登录屏幕并被迫登录。正如您可以想象的那样，这对我们的用户来说非常烦人和适得其反。

这是我在 web.config 中为根中的应用程序设置的内容：

<authentication mode="Forms">
      <forms name=".TcaNet"
        protection="All"
        timeout="40"
        loginUrl="~/Login.aspx"
        defaultUrl="~/MyHome.aspx"
        path="/"
        slidingExpiration="true"
        requireSSL="false" />
    </authentication>

我还读到，如果您的某些位置设置不再存在或者是虚假的，您可能会遇到问题。我的路径属性都是有效的目录，所以这不应该是问题：

<location path="js">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="images">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="anon">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="App_Themes">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>
  <location path="NonSSL">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

我唯一不清楚的是，我在表单属性中的身份验证票的超时值是否必须与我的会话超时值（在 IIS 中的应用程序配置中定义）相同。我读过一些东西说你应该让身份验证超时（40）比会话超时（45）更短，以避免可能的并发症。无论哪种方式，我们都有用户在他们最后一次操作后一两分钟被踢到登录屏幕。所以会话绝对不应该过期。

2009 年 2 月 23 日更新：我已经将会话超时和身份验证票证超时值都设置为 45，问题似乎仍然存在。

应用程序中唯一的其他 web.config 位于托管社区服务器的 1 个虚拟目录中。该 web.config 的身份验证设置如下：

<authentication mode="Forms">
            <forms name=".TcaNet" 
            protection="All" 
            timeout="40" 
            loginUrl="~/Login.aspx" 
            defaultUrl="~/MyHome.aspx" 
            path="/" 
            slidingExpiration="true" 
            requireSSL="true" />
        </authentication>

虽然我不认为它适用，除非您在网络花园中，但我将两个 web.config 文件中的机器键值设置为相同（为方便起见已删除）：

<machineKey 
        validationKey="<MYVALIDATIONKEYHERE>" 
        decryptionKey="<MYDECRYPTIONKEYHERE>" 
        validation="SHA1" />

<machineKey 
        validationKey="<MYVALIDATIONKEYHERE>" 
        decryptionKey="<MYDECRYPTIONKEYHERE>" 
        validation="SHA1"/>

对此的任何帮助将不胜感激。这似乎是产生大量谷歌结果的问题之一，到目前为止，这些结果似乎都不适合我的情况。

4

5 回答 5

2

检查应用程序池的Maximum Worker Processes 属性可能也是值得的。如果您在内存中使用会话并且有多个作为最大工作进程，您会发现会话问题，因为用户请求由不知道其会话的不同线程处理。

于 2009-02-24T20:13:41.230 回答
1

既然您已经注意到您正在为您的站点使用一个非常特定的 FQDN，那么您是否有任何其他 .Net 应用程序在相同的 FQDN 下运行，只是不同的虚拟路径？两个应用程序的身份验证 cookie 的名称可能相同，但令牌会不同。因此，如果我登录 www.domain.com，然后登录 www.domain.com/app2，我将不再对 app1 进行正确的身份验证。

于 2011-04-29T19:21:59.593 回答
0

1.) 检查您的 iis 进程被回收的频率。（打开日志记录并检查您的设置）。回收后，使用 proc 会话存储中的默认值，会话将丢失。

2.) 您的应用程序是否生成可能引发异常的线程（顺便说一句，不会向用户显示）？因为如果存在这种情况，iis 会更频繁地回收进程。

于 2009-02-19T18:36:02.920 回答
0

我刚刚完成了这个精确问题的处理，完全按照问题中的描述，问题是 web.config 中缺少一些配置。

使用 formsAuthentication 时，您需要停止让会话处理身份验证，因为 cookie 现在负责它。

需要在您的 Web 配置中的“system.web”元素中添加（或更新）这一行

<sessionState mode="Off">

sessionState 和 formsAuthentication 不应同时处于活动状态。我不了解它们如何相互干扰的细节，但在这种情况下，它会在随机时间产生随机用户的随机注销。

于 2015-09-10T04:54:03.387 回答
0

我们的网站多年来一直遇到同样的问题，但昨天我们找到了解决方法，请参阅我的问题。正如评论者建议的那样，我尝试将其添加到 web.config：

<sessionState mode="InProc" timeout="60" />

显然，必须在 sessionState 和票证中都设置超时。另请参阅https://msdn.microsoft.com/en-us/library/ms178586.aspx中的 ms 文档

为了在调试模式下更准确地测量实际超时，我发现在方法和Debug.WriteLine文件中添加调用很方便，使用添加毫秒时间Global.asax.csSession_Start()Session_End()

string.Format("{0:HH:mm:ss.fff} - {1}", DateTime.Now, strMessage);

这样您就可以登录，去吃午饭，让会话超时，并在 VisualStudio 输出窗口中的某个方便的时刻读取时间戳。

于 2016-08-10T09:19:21.930 回答