方案如下。我启动一个MVC应用程序实例来调试它。该应用程序使用简单的成员资格，我在此次运行期间登录。然后我回到VS改变一些东西并再次启动实例。它并不经常发生，但有时候会员开始表现得很奇怪。当应用程序启动时，会调用一些位于[Authorize]属性后面的操作（确切地说该属性位于控制器上）。但是，操作失败，因为WebSecurity.CurrentUserId等于-1（有问题的操作只是根据WebSecurity.CurrentUserId加载一些用户信息）。
如果我在浏览器中清除cookie，一切都很好，但我不能指望用户在遇到问题时也会这样做。
我的同事向我解释说它（可能）正在发生，因为我的本地IIS决定重新启动并且一些会话cookie变得无效，但如果这可能发生在IIS的本地实例上，那么也不可能发生远程服务器？
其他重要的事实是，我们编写的自定义过滤器会调用失败的操作（更像是重定向到）。此过滤器适用于所有操作（但不影响上述操作）。这个过滤器能否以某种方式使MVC忽略[Authorize]属性？
我有一个解决这个问题的肮脏的解决方法（使用这个特定的应用程序），但我宁愿防止问题出现在第一位。
我认为这与this有关。基本上当服务器重置时，身份验证cookie就会死掉。它们会立即重新创建，除非我的应用程序在页面重新加载之前无法访问它们（就像登录一样）。
我部分地解决了上面描述的问题（重定向在路上的某处执行），因此应用程序不再卡住。但是，如果某人在服务器重新启动期间登录并且他尝试在此之后预先形成帖子，则他的帖子将无效，他将被重定向到与post操作同名的get动作（我们的自定义过滤器是应该归咎于那个）。不幸的是我无法修复过滤器，因为我需要用户ID，并且在调用过滤器时，它仍然是-1。
答案 0 :(得分：0)
我想我的问题写得不太好，而且非常本地化（我应该重写它或重新编写它），但是底层问题比看起来更普遍，所以让我将所有有用的信息打包到这个答案
问题1：没有任何东西阻止IIS在远程服务器上打嗝并重新启动应用程序，所以是的，这可以（并且会发生）在远程服务器上（频率将取决于应用程序本身和IIS配置）。消失会话数据的问题似乎与重新启动应用程序池而不是应用程序本身有关。
问题2：自定义过滤器与情况无关。正如Larry指出的那样，简单的成员资格授权与会话数据无关。如果会话数据丢失，则用户不会停止授权，但用户数据将存储在会话中。没有会话，您不知道用户是谁。会话数据丢失后，此信息可用一个操作。因此，丢失会话数据可能会导致应用程序崩溃或类似我的情况（自定义过滤器依赖于用户数据）甚至更糟糕的结果。
因此，如果您的应用中遇到意外的用户数据消失（例如WebSecurity.CurrentUserId变为-1），则可能需要调查您的应用池是否重新启动（及其原因）。设置应用程序池的内存限制似乎会增加重新启动的可能性。