C# 清除浏览器历史记录时站点无法正常工作

我有一个旧的ASP.NET intranet应用程序，其中表单登录页显示了异常行为。如果IE的任何版本在提交登录页面时有一个清除的历史记录（历史记录，而不是cookies），则执行一个空白回发，并保留在登录页面上

如果他们刷新了页面，或者试图直接访问另一个页面而被重定向到登录页面，那么他们可以顺利登录

我已将此应用程序的其他副本发布到同一台IIS服务器上，它们最初没有表现出这种行为，但在一些小时后，它们开始以相同的方式运行。重新发布到同一实例不会像发布到新站点那样“修复”问题，删除旧应用程序然后发布到相同名称也不会

我不知道从这里到哪里去，所以任何帮助都将不胜感激

对我来说，以下是我的主要观察结果：

这只会影响我们的生产服务器。发布到其他两台服务器上的相同代码不会显示此缺陷。该代码已经运行多年，直到最近

我用响应替换了按钮点击代码。重定向到谷歌。当按钮运行不正常时，未触发此重定向。这向我表明按钮代码没有被执行。重新加载/刷新页面后，它会正确重定向，因为按钮代码现在正在触发

当相同的代码以不同的名称发布到此IIS服务器时，它在数小时内不会显示此缺陷。几小时后会发生什么导致这种行为改变？重新发布到同一IIS站点不会像发布到新的IIS站点那样在几个小时内解决此问题

我已经从这篇文章中删除了按钮代码，因为我认为这是一个转移视线的问题，因为代码似乎根本没有被执行

这就是站点运行时网络工具中cookie的样子

从站点工作到不工作的区别在于Form1键被标记为已发送且未接收

我还注意到，当站点不工作时，favicon显示为（已中止）。我现在认为请求被完全中止，因为我已经覆盖了页面的OnInit，并且当站点不工作时，我输入的代码没有被执行

---

今天，我的工作为解决这个问题向微软开出了一张罚单，他们说这是一个“头痛的问题”。

我不同意Nick的观点，因为你的断言代码中存在问题：

这只会影响我们的生产服务器。发布到其他两台服务器上的相同代码不会显示此缺陷。该代码已经运行多年，直到最近

这表明服务器之间存在差异，它们的配置方式或阻止其工作的代码的部署方式也存在差异。由于这是一个表单身份验证问题，我想起了IE10中破坏表单身份验证的错误-参见

---

您的服务器相同吗？运行相同的操作系统、.NET版本、修补程序、修补程序等？

微软挽救了这一天

---

他们告诉我们，旧版本的IE将在IIS的根文件夹中查找favicon，而不是应用程序路径，无论您将其指向何处。我们发现根文件夹的身份验证设置仅设置为Windows身份验证。无论出于何种原因，这导致表单身份验证中止，直到我们将Allow Anonymous添加到根文件夹。

正在逐步检查代码以确保没有发生内部错误？如果没有看到代码，很难知道原因是什么。有几种可能导致这种情况的因素，它们很可能位于应用程序代码本身，而不是IIS配置中。我首先要寻找的是错误处理、基于用户和应用程序会话的存储，以及其他与用户或应用程序上下文有关的内容。这就是我在NickI的代码中编辑的内容。这段代码已经运行了多年，直到最近，所以我认为这不会是代码的问题。我现在了解到，当发生此错误时，该站点甚至没有执行按钮单击代码。请查看我最近的编辑。至于您关于服务器相同的问题，很遗憾，答案是肯定的。您在生产中有负载平衡吗？请求是否会因为不匹配的计算机密钥而无法进行身份验证？为了好玩，您可以尝试更改为无cookieless身份验证，看看这是否会有所不同。