Сценарий таков. Я запускаю экземпляр приложения MVC для его отладки. Приложение использует простое членство, и я во время этого входа в систему. Затем я возвращаюсь к VS, что-то меняю и снова запускаю экземпляр. Это случается не часто, но иногда в этот момент членство начинает действовать странно. Когда приложение запускается, какое-то действие позади[Authorize] Атрибут (а точнее атрибут находится на контроллере), вызывается. Однако действие терпит неудачу, потому чтоWebSecurity.CurrentUserId равно -1 (рассматриваемое действие просто загружает некоторую информацию о пользователе на основеWebSecurity.CurrentUserId).

Если я удаляю куки в браузере, все в порядке, но я не могу ожидать, что пользователи будут делать то же самое, когда сталкиваются с проблемой.

Мой коллега объяснил мне, что это (возможно) происходит из-за того, что мой локальный IIS решил перезапустить, и некоторые из файлов cookie сеанса стали недействительными, но если это может произойти на локальном экземпляре IIS, не будет ли это также возможно на удаленном сервере ?

Другим важным фактом является то, что неудачное действие вызывается (скорее как перенаправление) настраиваемым фильтром, который мы написали. Этот фильтр применяется ко всем действиям (но не влияет на упомянутое). Может ли этот фильтр как-то заставить MVC игнорировать[Authorize] атрибут?

У меня есть грязный обходной путь для этой проблемы, который должен работать (с этим определенным приложением), но я предпочел бы предотвратить появление проблемы в первую очередь.

Я думаю, что это связано сэтот, В основном, когда сервер получает сброс аутентификации, cookie-файлы умирают. Они воссоздаются сразу, за исключением того, что мое приложение не имеет к ним доступа, пока страница не будет перезагружена (как при входе в систему).

Я частично решил проблему, описанную выше (перенаправление где-то в пути), поэтому приложение больше не застревает. Однако, если кто-то вошел в систему во время перезапуска сервера, и после этого он пытается подготовить сообщение, его сообщение не будет работать, и он будет перенаправлен на действие get с тем же именем, что и действие публикации (наш пользовательский фильтр виноват в этом). К сожалению, я не могу исправить фильтр, потому что для этого мне понадобится идентификатор пользователя, и в тот момент, когда фильтр вызывается, он по-прежнему равен -1.