Lorsque vous vous préparez à mettre à niveau votre application Web d'ASP.NET 1.1 vers ASP.NET 2.0, vous serez confronté à un problème de cookies : tous les cookies enregistrés par le client dans l'application ASP.NET 1.1 deviendront invalides.
Blog Park a également rencontré un tel problème. Pour Blog Park, cela signifie que tous les utilisateurs qui utilisent des cookies doivent se reconnecter. Bien que ce ne soit pas un gros problème, cela posera des problèmes à tout le monde. plus gênant.
Pour un site Web qui attache une grande importance à la satisfaction des utilisateurs, des efforts doivent être faits pour résoudre ce problème. Blog Park espère réduire autant que possible l'impact de la mise à niveau, j'ai donc étudié ce problème ces deux derniers jours et j'ai trouvé une solution.
La cause du problème est la suivante : lorsque le programme est mis à niveau d'ASP.NET 1.1 vers ASP.NET 2.0, ASP.NET 2.0 utilise un nouvel algorithme et une nouvelle clé pour déchiffrer le cookie envoyé par le client, ce qui entraîne que les cookies ne sont pas valides dans ASP.NET 2.0. Dans ASP.NET 1.1, l'algorithme 3DES est utilisé pour chiffrer le contenu du cookie, tandis que dans ASP.NET 2.0, l'algorithme Advanced Encrypted Standards (AES) est utilisé par défaut pour décrypter. C'est l'une des causes du problème. . Vous pouvez utiliser les paramètres correspondants pour modifier l'algorithme de chiffrement des cookies dans ASP.NET 2.0 en 3DES, ajoutez simplement : <machineKey decryption="3DES"/> à web.config. Mais après cela, le problème persiste, car en plus du même algorithme, la même clé est également requise pour le décryptage. Si aucune clé n'est spécifiée dans machineKey, ASP.NET 2.0 utilisera par défaut une clé générée aléatoirement. Cette clé aléatoire est générée par System.Web.HttpRuntime.SetAutogenKeys() et stockée dans System.Web.HttpRuntime.s_autogenKeys. cette valeur par la réflexion. La machineKey d'ASP.NET 1.1 est définie dans machine.config, et une clé aléatoire est également utilisée par défaut :
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>.
Le problème réside dans les différentes clés aléatoires. Si vous avez spécifié la clé dans l'ASP.NET 1.1 d'origine, ce problème n'existerait pas, mais cela est généralement pris en compte lors de l'utilisation de batteries de serveurs Web. Donc, généralement, une clé aléatoire est utilisée. ASP.NET générera différentes clés aléatoires pour différentes applications. Ce problème d'échec des cookies client se produira dans de nombreuses situations, telles que : la réinstallation du système, le déplacement de l'application ASP.NET vers un autre ordinateur, l'application Web est déplacée vers un autre répertoire virtuel. et ainsi de suite.
Comment résoudre ce problème ?
Le principe est très simple, à condition de connaître la valeur de la clé générée aléatoirement dans ASP.NET 1.1, puis de la spécifier dans le web.config de l'application ASP.NET 2.0. Il y a ici deux clés : l'une est le chiffrement. La clé decryptionKey, l'une est la clé de calcul de hachage validationKey (pour empêcher le cookie d'être falsifié à mi-chemin). Si on sait que les clés sont : X et Y, alors dans web.config
Le problème peut être résolu en effectuant les réglages suivants :
<machineKey validationKey="X" decryptionKey="Y" decryption="3DES"/>
Le problème est de savoir comment obtenir la valeur de la clé générée aléatoirement dans ASP.NET 1.1. La clé est stockée dans le LSA (Windows Local Security Authority), mais je n'ai pas trouvé de moyen d'obtenir la clé du LSA.
Étant donné que le parc de blogs résout principalement le problème des cookies de connexion et que ce cookie est généré dans System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPersistentCookie), j'ai donc commencé à partir de System.Web.Security d'ASP.NET 1.1. avec le code source de .FormsAuthentication, j'ai découvert System.Web.Configuration.MachineKey Après des recherches plus approfondies sur le code source de MachineKey, j'ai trouvé deux clés dans MachineKeyConfig de MachineKey, qui existent dans les deux membres statiques privés de s_validationKey et s_oDes (. Il a fallu beaucoup d'efforts pour découvrir cela), la valeur de validationKey est stockée directement dans s_validationKey et la decryptionKey est stockée dans s_oDes.Key. Étant donné que MachineKey est une classe interne et que MachineKeyConfig est un type privé, ces deux membres sont des membres statiques privés et ne sont pas accessibles directement. À l’heure actuelle, il est temps que la puissante fonction de réflexion de .NET entre en jeu. Ces deux valeurs sont obtenues par réflexion. Il est à noter que le type de ces deux valeurs est Byte[]. Grâce aux tests, il s'avère que la clé générée en la convertissant directement en chaîne n'est pas valide. Vous devez appeler System.Web.Configuration.MachineKey.ByteArrayToHexString via la réflexion (Byte[], Int32) convertie en chaîne.
J'ai enfin résolu ce problème ce soir, tellement excité ! J'ai voulu abandonner plusieurs fois au milieu, mais j'ai pensé qu'après la mise à niveau du programme Blog Park vers ASP.NET 2.0, ce problème causerait des problèmes à de nombreuses personnes. Bien que je n'aie qu'à me reconnecter, j'ai toujours le sentiment que. Je dois résoudre ce problème et le faire. Le développement de programmes n'est-il pas destiné à apporter autant de commodité aux utilisateurs que possible ?
La résolution de ce problème nécessitera des préparatifs supplémentaires pour la mise à niveau du site Web Blog Park vers ASP.NET 2.0.
Source : programmeur dudu-happy