Cuando se prepare para actualizar su aplicación web de ASP.NET 1.1 a ASP.NET 2.0, se enfrentará a un problema de cookies: todas las cookies guardadas por el cliente en la aplicación ASP.NET 1.1 dejarán de ser válidas.
Blog Park también ha encontrado un problema de este tipo. Para Blog Park, significa que todos los usuarios que usan cookies deben iniciar sesión nuevamente. Aunque esto no es un gran problema, traerá problemas a todos. más problemático.
Para un sitio web que concede gran importancia a la satisfacción del usuario, se deben hacer esfuerzos para resolver este problema. Blog Park espera reducir el impacto de la actualización tanto como sea posible, por lo que estuve estudiando este problema durante los últimos dos días y encontré una solución.
La causa del problema es: cuando el programa se actualiza de ASP.NET 1.1 a ASP.NET 2.0, ASP.NET 2.0 utiliza un nuevo algoritmo y clave para descifrar la cookie enviada por el cliente, lo que da como resultado que las cookies no sean válidas en ASP.NET 2.0. En ASP.NET 1.1, se utiliza el algoritmo 3DES para cifrar el contenido de la cookie, mientras que en ASP.NET 2.0, el algoritmo de Estándares de cifrado avanzados (AES) se utiliza de forma predeterminada para descifrar. Esta es una de las causas del problema. Puede utilizar la configuración correspondiente para cambiar el algoritmo de cifrado de cookies en ASP.NET 2.0 a 3DES, simplemente agregue: <machineKey decryption="3DES"/> a web.config. Pero después de hacer esto, el problema persiste, porque además del mismo algoritmo, también se requiere la misma clave para descifrar. Si no se especifica ninguna clave en machineKey, ASP.NET 2.0 utilizará una clave generada aleatoriamente de forma predeterminada. Esta clave aleatoria es generada por System.Web.HttpRuntime.SetAutogenKeys() y se almacena en System.Web.HttpRuntime.s_autogenKeys. este valor a través de la reflexión. La clave de máquina de ASP.NET 1.1 está configurada en machine.config y también se utiliza una clave aleatoria de forma predeterminada:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>.
El problema radica en las diferentes claves aleatorias. Si especificara la clave en el ASP.NET 1.1 original, este problema no existiría, pero esto generalmente se considera cuando se utilizan granjas de servidores web. Por lo general, se utiliza una clave aleatoria. ASP.NET generará diferentes claves aleatorias para diferentes aplicaciones. Este problema de falla de las cookies del cliente ocurrirá en muchas situaciones, tales como: reinstalar el sistema, mover la aplicación ASP.NET a otra computadora, la aplicación web se mueve a un directorio virtual diferente. etcétera.
¿Cómo solucionar este problema?
El principio es muy simple, siempre que conozcamos el valor de la clave generada aleatoriamente en ASP.NET 1.1 y luego lo especifiquemos en el archivo web.config de la aplicación ASP.NET 2.0. Aquí hay dos claves: una es el cifrado. La clave de descifrado, una es la clave de validación de la clave de cálculo hash (para evitar que la cookie sea manipulada a mitad de camino). Si sabemos que las claves son: X e Y, entonces en web.config
El problema se puede solucionar realizando los siguientes ajustes:
<machineKey validaciónKey="X" decryptionKey="Y" decryption="3DES"/>
El problema es cómo obtener el valor de la clave generada aleatoriamente en ASP.NET 1.1. La clave está almacenada en LSA (Autoridad de seguridad local de Windows), pero no encontré una manera de obtener la clave de LSA.
Dado que el parque de blogs resuelve principalmente el problema de las cookies de inicio de sesión, y esta cookie se genera en System.Web.Security.FormsAuthentication.SetAuthCookie (string userName, bool createPersistentCookie), comencé desde System.Web.Security de ASP.NET 1.1. con el código fuente de .FormsAuthentication, descubrí System.Web.Configuration.MachineKey. Después de investigar más sobre el código fuente de MachineKey, encontré dos claves en MachineKeyConfig de MachineKey, que existen en los dos miembros estáticos privados de s_validationKey y s_oDes (. Se requirió mucho esfuerzo para descubrir esto), el valor de validationKey se almacena directamente en s_validationKey y decryptionKey se almacena en s_oDes.Key. Dado que MachineKey es una clase interna y MachineKeyConfig es un tipo privado, esos dos miembros son miembros estáticos privados y no se puede acceder a ellos directamente. En este momento, es hora de que entre en juego la poderosa función de reflexión en .NET. Estos dos valores se obtienen mediante reflexión. Cabe señalar que el tipo de estos dos valores es Byte []. Al realizar pruebas, se descubre que la clave generada al convertirla directamente en una cadena no es válida. Debe llamar a System.Web.Configuration.MachineKey.ByteArrayToHexString mediante reflexión (Byte[], Int32) convertido a cadena.
Finalmente resolví este problema esta noche, ¡qué emoción! Quise rendirme varias veces en el medio, pero pensé que después de que el programa del parque de blogs se actualizara a ASP.NET 2.0, este problema causaría problemas a muchas personas. Aunque solo necesito iniciar sesión nuevamente, todavía siento eso. Necesito resolver este problema y ¿no está destinado el desarrollo de programas a brindar la mayor comodidad posible a los usuarios?
Resolver este problema requerirá más preparativos para actualizar el sitio web de Blog Park a ASP.NET 2.0.
Fuente: programador dudu-feliz