Das Szenario ist wie folgt. Ich starte eine Instanz der MVC-App, um sie zu debuggen. Die App verwendet eine einfache Mitgliedschaft und ich melde mich während dieses Laufs an. Dann gehe ich zurück zu VS, ändere etwas und starte die Instanz erneut. Es kommt nicht oft vor, aber manchmal wird die Mitgliedschaft in diesem Moment merkwürdig. Als die App startet, ist eine Aktion dahinter[Authorize] attribute (um genau zu sein, das Attribut befindet sich auf dem Controller), wird aufgerufen. Die Aktion schlägt jedoch fehl, weilWebSecurity.CurrentUserId ist gleich -1 (die fragliche Aktion lädt nur einige Benutzerinformationen basierend aufWebSecurity.CurrentUserId).

Wenn ich Cookies im Browser lösche, ist alles in Ordnung, aber ich kann nicht erwarten, dass Benutzer dasselbe tun, wenn sie auf das Problem stoßen.

Mein Kollege hat mir erklärt, dass dies (wahrscheinlich) darauf zurückzuführen ist, dass mein lokaler IIS einen Neustart beschlossen hat und einige Sitzungscookies ungültig wurden. Wenn dies jedoch auf einer lokalen IIS-Instanz geschehen kann, ist dies nicht auch auf dem Remoteserver möglich ?

Eine weitere wichtige Tatsache ist, dass die fehlgeschlagene Aktion von einem benutzerdefinierten Filter, den wir geschrieben haben, aufgerufen (eher umgeleitet) wird. Dieser Filter wird auf alle Aktionen angewendet (wirkt sich jedoch nicht auf die genannten aus). Kann dieser Filter MVC irgendwie ignorieren lassen[Authorize] Attribut?

Ich habe eine fehlerhafte Problemumgehung für dieses Problem, die funktionieren sollte (mit dieser speziellen App), aber ich würde es vorziehen, zu verhindern, dass das Problem überhaupt erst auftritt.

Ich denke, das hängt damit zusammendiese. Grundsätzlich sterben Authentifizierungs-Cookies, wenn der Server zurückgesetzt wird. Sie werden sofort neu erstellt, mit der Ausnahme, dass meine App nicht wirklich auf sie zugreifen kann, bis die Seite neu geladen wird (genau wie beim Anmelden).

Ich habe das oben beschriebene Problem teilweise gelöst (eine Umleitung wird unterwegs durchgeführt), sodass die Anwendung nicht mehr hängen bleibt. Wenn jedoch jemand während des Neustarts des Servers angemeldet war und danach versucht, einen Beitrag vorzubereiten, funktioniert sein Beitrag nicht und er wird zu einer Abrufaktion mit demselben Namen wie die Beitragsaktion umgeleitet (unser benutzerdefinierter Filter lautet schuld daran). Leider kann ich den Filter nicht reparieren, da ich dafür eine Benutzer-ID benötige und an dem Punkt, an dem der Filter aufgerufen wird, immer noch -1 ist.