Wenn Sie sich darauf vorbereiten, Ihre Webanwendung von ASP.NET 1.1 auf ASP.NET 2.0 zu aktualisieren, werden Sie mit einem Cookie-Problem konfrontiert: Alle vom Client in der ASP.NET 1.1-Anwendung gespeicherten Cookies werden ungültig.
Auch bei Blog Park ist ein solches Problem aufgetreten. Das bedeutet, dass sich alle Benutzer, die Cookies verwenden, erneut anmelden müssen. Wenn Sie Ihr Passwort vergessen, ist dies jedoch kein großes Problem lästiger.
Für eine Website, die großen Wert auf die Zufriedenheit der Benutzer legt, sollten Anstrengungen unternommen werden, um dieses Problem zu lösen. Blog Park hofft, die Auswirkungen des Upgrades so weit wie möglich zu reduzieren. Deshalb habe ich dieses Problem in den letzten zwei Tagen untersucht und eine Lösung gefunden.
Die Ursache des Problems ist: Wenn das Programm von ASP.NET 1.1 auf ASP.NET 2.0 aktualisiert wird, verwendet ASP.NET 2.0 einen neuen Algorithmus und Schlüssel, um das vom Client gesendete Cookie zu entschlüsseln, was dazu führt, dass die Cookies ungültig sind ASP.NET 2.0. In ASP.NET 1.1 wird der 3DES-Algorithmus zum Verschlüsseln des Cookie-Inhalts verwendet, während in ASP.NET 2.0 standardmäßig der Advanced Encrypted Standards (AES)-Algorithmus zum Entschlüsseln verwendet wird. Dies ist eine der Ursachen des Problems . Sie können die entsprechenden Einstellungen verwenden, um den Cookie-Verschlüsselungsalgorithmus in ASP.NET 2.0 auf 3DES zu ändern. Fügen Sie einfach Folgendes hinzu: <machineKey decryption="3DES"/> zu web.config. Danach besteht das Problem jedoch immer noch, da zur Entschlüsselung neben dem gleichen Algorithmus auch der gleiche Schlüssel benötigt wird. Wenn in machineKey kein Schlüssel angegeben ist, verwendet ASP.NET 2.0 standardmäßig einen zufällig generierten Schlüssel. Dieser zufällige Schlüssel wird von System.Web.HttpRuntime.SetAutogenKeys () generiert und in System.Web.HttpRuntime.s_autogenKeys gespeichert diesen Wert durch Reflexion. Der machineKey von ASP.NET 1.1 wird in machine.config festgelegt und standardmäßig wird auch ein zufälliger Schlüssel verwendet:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>.
Das Problem liegt in den unterschiedlichen Zufallsschlüsseln. Wenn Sie den Schlüssel im ursprünglichen ASP.NET 1.1 angegeben hätten, bestünde dieses Problem nicht, wird jedoch im Allgemeinen bei der Verwendung von Webfarmen berücksichtigt. Daher wird normalerweise ein zufälliger Schlüssel verwendet. ASP.NET generiert unterschiedliche Zufallsschlüssel für verschiedene Anwendungen. Dieses Client-Cookie-Fehlerproblem tritt in vielen Situationen auf, z. B. bei einer Neuinstallation des Systems, beim Verschieben der ASP.NET-Anwendung auf einen anderen Computer oder beim Verschieben der Webanwendung in ein anderes virtuelles Verzeichnis und so weiter.
Wie kann dieses Problem gelöst werden?
Das Prinzip ist sehr einfach, solange wir den Wert des zufällig generierten Schlüssels in ASP.NET 1.1 kennen und ihn dann in der web.config der ASP.NET 2.0-Anwendung angeben. Hier gibt es zwei Schlüssel: Einer ist die Verschlüsselung Der Schlüssel decryptionKey, einer davon ist der Hash-Berechnungsschlüssel validationKey (um zu verhindern, dass das Cookie auf halbem Weg manipuliert wird). Wenn wir wissen, dass die Schlüssel X und Y sind, dann in web.config
Das Problem lässt sich durch folgende Einstellungen lösen:
<machineKey validationKey="X" decryptionKey="Y" decryption="3DES"/>
Das Problem besteht darin, wie man den Wert des zufällig generierten Schlüssels in ASP.NET 1.1 erhält. Der Schlüssel ist in der LSA (Windows Local Security Authority) gespeichert, aber ich habe keine Möglichkeit gefunden, den Schlüssel von der LSA zu erhalten.
Da der Blogpark hauptsächlich das Problem der Anmeldecookies löst und dieses Cookie in System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPersistentCookie) generiert wird, habe ich mit System.Web.Security von ASP.NET 1.1 begonnen Mit dem Quellcode von .FormsAuthentication habe ich System.Web.Configuration.MachineKey entdeckt. Nach weiteren Recherchen zum Quellcode von MachineKey habe ich zwei Schlüssel in MachineKeys MachineKeyConfig gefunden, die in den beiden privaten statischen Mitgliedern von s_validationKey und s_oDes vorhanden sind. Es hat viel Mühe gekostet, dies herauszufinden. Der Wert von validationKey wird direkt in s_validationKey gespeichert, und der decryptionKey wird in s_oDes.Key gespeichert. Da MachineKey eine interne Klasse und MachineKeyConfig ein privater Typ ist, sind diese beiden Mitglieder private statische Mitglieder, auf die nicht direkt zugegriffen werden kann. Zu diesem Zeitpunkt ist es an der Zeit, dass die leistungsstarke Reflexionsfunktion in .NET ins Spiel kommt. Diese beiden Werte werden durch Reflektion erhalten. Es ist zu beachten, dass der Typ dieser beiden Werte Byte[] ist. Durch Tests wurde festgestellt, dass der durch direkte Konvertierung in eine Zeichenfolge generierte Schlüssel ungültig ist. Sie müssen System.Web.Configuration.MachineKey.ByteArrayToHexString durch Reflektion (Byte[], Int32) in einen String konvertieren.
Ich habe dieses Problem heute Abend endlich gelöst, ich bin so aufgeregt! Ich wollte mittendrin mehrmals aufgeben, dachte aber, dass dieses Problem nach dem Upgrade des Blogpark-Programms auf ASP.NET 2.0 vielen Leuten Probleme bereiten würde. Obwohl ich mich nur erneut anmelden muss, habe ich immer noch das Gefühl Ich muss dieses Problem lösen. Ist die Programmentwicklung nicht darauf ausgelegt, den Benutzern so viel Komfort wie möglich zu bieten?
Um dieses Problem zu lösen, werden weitere Vorbereitungen für das Upgrade der Blog Park-Website auf ASP.NET 2.0 getroffen.
Quelle: dudu-happy-Programmierer