0

我有一个相当大规模的 Web 应用程序与运行在 Intranet 上的多个应用程序通信。默认会话超时为 20 分钟。此应用程序具有某些可编辑的小部件。此应用程序的某些用户在仅登录几分钟后在小部件上编辑数据时经历了随机注销。我没有在我的机器上看到这样的注销。如何解决此类注销问题？

应用程序日志经常有以下类型的条目

事件代码：4005 事件消息：请求的表单身份验证失败。原因：提供的票已过期。事件时间：19/09/2013 16:19:00 事件时间 (UTC)：19/09/2013 15:19:00 事件 ID：bfedac01cc514bedb236347b8585a4e3 事件序列：31083 事件发生：820 事件详细代码：50202

应用信息：应用域：/xx/xxxxxxx 信任等级：完整应用虚拟路径：/应用路径：C:\xxx\xxx\机器名：xxxxx

进程信息：进程 ID：56940 进程名称：w3wp.exe 帐户名称：NT AUTHORITY\NETWORK SERVICE

请求信息： 请求URL：http://www.xxxx 请求路径：/xxxxx.aspx 用户主机地址：xxx.xxx.xxx.205 用户：已
认证：False 认证类型：
线程账号名：NT AUTHORITY\NETWORK SERVICE

要验证的名称：

4

1 回答 1

3

解决此类意外注销的唯一可靠方法是要求用户使用客户端 http 调试器（如 Fiddler）记录他们的会话。

在客户端后台打开 fiddler 运行您的应用程序将记录所有请求和响应。然后，当发生意外故障时，用户选择完整的跟踪（所有请求），将所有内容导出到文件并发送给您。

然后，作为开发人员，您打开 Fiddler，导入用户跟踪并围绕失败的请求对其进行分析。

您搜索的是关于 cookie 的响应行为。通常，表单身份验证 cookie 与请求一起发送到服务器，以便对用户进行身份验证。另一方面，失败的请求可能应该没有这样的 cookie，这表明它已被以某种方式删除。

这就是它变得有趣的地方。删除 cookie 的唯一方法是手动删除它或从删除 cookie 的服务器接收事先响应。从您的开发人员的角度来看，删除 cookie 是在您调用FormsAuthentication.SignOut.

在分析跟踪时，您只是试图找到罪魁祸首请求-请求失败之前的请求 - 导致 cookie 在客户端被删除的请求。

这种罪魁祸首请求中有什么特别之处 - 它取决于您的服务器端代码，并且有许多可能的原因，从配置问题到错误代码。

但是，这绝对是您开始调查的一种方式。

于 2013-09-19T11:04:57.213 回答