<machineKey decryptionKey = "AutoGenerate" ... wird von IIS ignoriert. Die Cookies der vorherigen Sitzung werden nicht ungültig

(Siehe Frage unten für mehr Kontext):

Gibt es Situationen, in denen

<machineKey
      validationKey="AutoGenerate,IsolateApps"
      decryptionKey="AutoGenerate,IsolateApps"/>

in web.config würde fehlschlagen, einen neuen Computerschlüssel beim App-Pool-Recycling automatisch zu generieren? Das ist das Verhalten, das ich sehe ...

Ich verwende die standardmäßige ASP.NET FormsAuthentication in einer MVC-App. Wenn ich einen Benutzer mit anmeldeFormsAuthentication.GetAuthCookie Wenn Sie kein dauerhaftes Cookie verwenden (das sich auf die Sitzung des Browsers stützt, um sich an meinen autorisierten Status zu erinnern), würde ich davon ausgehen, dass durch das Recycling des IIS-App-Pools das Wissen der Sitzung über dieses Cookie ungültig wird ... und sich daher von allen Benutzern abmelden, die nicht über dieses Cookie verfügen dauerhafte Cookies.

Dies geschieht auf einer meiner IIS-Installationen (XP), aber auf einer anderen IIS-Konfiguration (Server 2K3) bleibt das FormsAuthentication-Cookie (unter dem Standardnamen ".ASPXAUTH") gültig und autorisiert den Benutzer weiterhin.

Weiß jemand, warum dies geschieht oder welche Konfiguration dieses Verhalten steuert?

Offensichtlich hat das Recycling des App-Pools keine Kontrolle darüber, ob der Browser weiterhin das .ASPXAUTH-Cookie sendet oder nicht (solange ich meinen Browser nicht geschlossen habe und das Cookie nicht abgelaufen ist).

Bei der IIS-Installation, bei der die Authentifizierung nach einem Recycling ordnungsgemäß verweigert wird, wird das eingehende Cookie in angezeigtRequest.Cookies während derApplication_BeginRequest event ... aber sobald die Steuerung zum nächsten in Global.asax.cs verfügbaren Ereignis wechselt(Application_AuthenticateRequest) wurde der Cookie von der entferntRequest.Cookies Sammlung.

Warum geschieht dies nicht für beide IIS / ASP.NET-Konfigurationen?

Falls dies nicht klar ist, ist eine einfachere Form der Fragestellung:

Warum tutHttpContext.Current.Request.Cookies[".ASPXAUTH"] Wechsel von{System.Web.HttpCookie} auf null setzen, wenn ich in einer einzelnen Anfrage vonApplication_BeginRequest zuApplication_AuthenticateRequest?

Weitere Debugging-Informationen:

Wenn ich den folgenden Code an das FormsAuthentication_OnAuthenticate-Ereignis von Global.asax.cs anhänge ...

var cookie = Request.Cookies[FormsAuthentication.FormsCookieName];
if (cookie != null)
{
    var val = cookie.Value;
    try
    {
        FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(val);
    }
    catch (Exception)
    {
    }
}

... dann bei einer AnfrageVor Wenn ich den IIS-App-Pool erneut verwende, wird keine Ausnahme abgefangen. Nach dem Recycling des IIS-App-Pools wird beim Senden des exakt gleichen .ASPXAUTH-Cookies vom Browser eine kryptografische Ausnahme abgefangen ("Padding ist ungültig und kann nicht entfernt werden.").

Warum ist das?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage