MVC应用程序在服务器重新启动后遇到错误 [英] MVC app getting stuck on an error after server restart
问题描述
方案如下。我开始一个MVC应用程序的实例来调试它。该应用程序使用简单的成员资格，我在此运行期间登录。然后我回到VS更改的东西，并再次启动实例。它不会真的经常发生，但有时在这一刻会员开始表现奇怪。当应用程序启动时，一些动作，即 [Authorize] 属性（确切的属性在控制器上）被调用。但是操作失败，因为 WebSecurity.CurrentUserId 等于-1（有问题的操作只加载一些用户信息基于 WebSecurity.CurrentUserId ）。
如果我在浏览器中清除cookie，一切都很好，但我不能指望用户在遇到问题时也这样做。 p>
我的同事向我解释，它是（可能）发生，因为我的本地IIS决定重新启动，一些会话cookie变得无效，但如果这可能发生在IIS的本地实例，
其他重要的事实，失败的动作被一个自定义过滤器调用（更像重定向到）我们写。此过滤器应用于所有操作（但不会影响所提到的操作）。可以这个过滤器以某种方式使MVC忽略 [Authorize] 属性？
我有一个脏的解决方法，工作（与这个特定的应用程序），但我宁愿防止问题出现int第一。
认为这与此相关。基本上当服务器获得重置身份验证cookie时。它们会立即重新创建，除非我的应用程序真的没有访问他们，直到页面重新加载（就像登录）。
我部分解决了问题（重定向在路上的某个地方执行），因此应用程序不再卡住。但是，如果有人在服务器重新启动期间登录，并且他尝试在此之后发布帖子，那么他的帖子将无法正常工作，并且将被重定向到与帖子动作相同的get操作（我们的自定义过滤器为此责怪）。不幸的是，我不能修复过滤器，因为我需要用户id，在过滤器被调用的点，它仍然是-1。
我想我的问题不是很好的书面和种类非常本地化（我应该重写它或reask它），但底层的问题是比一般比看起来，所以让我救救所有的有用的信息到这个答案。
问题1：没有什么阻止IIS在远程服务器上打嗝，并重新启动应用程序，所以是这可以（并发生）远程服务器（频率将取决于应用程序本身和IIS配置）。消失的会话数据的问题似乎与应用程序池的重新启动而不是应用程序本身有关。
问题2：自定义过滤器与情况。正如Larry所指出的，简单成员资格授权与会话数据无关。如果会话数据丢失，用户不会停止授权，但用户数据存储在会话中。没有会话，你不知道用户是谁。在会话数据丢失后，此信息变为可用一个操作。因此，如果丢失会话数据，可能导致应用程序崩溃，或者在我的情况下（自定义过滤器取决于用户数据），甚至更糟糕的结果。
遇到用户数据在您的应用程序中意外消失（例如 WebSecurity.CurrentUserId 成为-1），可能值得调查您的应用程序池是否正在重新启动（以及为什么）。设置应用池的内存限制似乎会增加重新启动的可能性。
The scenario is as follows. I start an instance of MVC app to debug it. The app uses simple membership and I log in during this run. Then I go back to VS change something and start the instance again. It doesn't happen really often but sometimes at this moment membership starts acting odd. As the app starts, some action, that is behind [Authorize] attribute (to be exact the attribute is on the controller), is called. However the action fails because WebSecurity.CurrentUserId is equal -1 (the action in question just loads some user information based on WebSecurity.CurrentUserId).
If I clear cookies in browser, everything is fine, but I can't expect users to do the same when they encounter the problem.
My colleague explaind to me that it's (probably) happening because my local IIS decided to restart and some of session cookies became invalid, but if this can happen on local instance of IIS, wouldn't it be possible to also happen on the remote server?
Other important fact, the action that fails is called (more like redirected to) by a custom filter that we wrote. This filter is applied to all actions (but doesn't affect the one mentioned). Can this filter somehow make MVC ignore [Authorize] attribute?
I have a dirty workaround for this problem that should work (with this specific app), but I would prefer to prevent the problem from appearing int the first place.
I think this is related to this. Basically when the server gets reset authentication cookies die. They get recreated right away, except my app doesn't really have access to them till the page is reloaded (just like with logging in).
I partially solved the problem described above (a redirect is preformed somewhere on the way) so the application no longer gets stuck. However, if someone was logged in during the time the server restarted and he tries to preform a post after that, his post will not work and he will be redirected to a get action with the same name as the post action (our custom filter is to blame for that). Unfortunately I cannot fix the filter, because I would need user id for that and at the point at which the filter is called, it's still -1.
I guess my question is not too well written and kind of very localized (I should probably rewrite it or reask it), but the underlaying problem is more general than it seems, so let me salvage all the useful information into this answer.
Question 1: There is nothing preventing IIS from having a hiccup on a remote server and restarting the app, so yes this can (and happens) on the remote server (frequency will depend on the app itself and IIS configuration). The problem of disappearing session data seems to be related to the restarts of the app pool rather than the app itself.
Question 2: The custom filter has little to do with the situation. As pointed by Larry, in simple membership authorization is kind of unrelated to session data. If your session data is lost, the user does not stop being authorized, however user data is stored in the session. Without session you don't know who the user is. This information becomes available one action after session data was lost. So loosing session data can lead to a crash of the application or like in my case (where a custom filter depends on user data) to even weirder results.
So if you encounter unexpected disappearance of user data in your app (such as WebSecurity.CurrentUserId becoming -1), it might be worth investigating if your app pool is getting restarted (and why). Setting memory limits for an app pool seems to increase the likelihood of those restarts.
这篇关于MVC应用程序在服务器重新启动后遇到错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
