Ao se preparar para atualizar seu aplicativo Web do ASP.NET 1.1 para o ASP.NET 2.0, você enfrentará um problema de cookie: todos os cookies salvos pelo cliente no aplicativo ASP.NET 1.1 se tornarão inválidos.
O Blog Park também encontrou esse problema. Para o Blog Park, isso significa que todos os usuários que usam cookies precisam fazer login novamente. Embora isso não seja um grande problema, será um problema para todos. mais problemático.
Para um site que dá grande importância à satisfação do usuário, esforços devem ser feitos para solucionar este problema. O Blog Park espera reduzir ao máximo o impacto da atualização, por isso tenho estudado esse problema nos últimos dois dias e encontrei uma solução.
A causa do problema é: quando o programa é atualizado do ASP.NET 1.1 para o ASP.NET 2.0, o ASP.NET 2.0 usa um novo algoritmo e chave para descriptografar o cookie enviado pelo cliente, o que resulta nos Cookies são inválidos em ASP.NET 2.0. No ASP.NET 1.1, o algoritmo 3DES é usado para criptografar o conteúdo do cookie, enquanto no ASP.NET 2.0, o algoritmo Advanced Encrypted Standards (AES) é usado por padrão para descriptografar. . Você pode usar as configurações correspondentes para Para alterar o algoritmo de criptografia de cookies no ASP.NET 2.0 para 3DES, basta adicionar: <machineKey decryption="3DES"/> ao web.config. Mas depois de fazer isso, o problema ainda existe, pois além do mesmo algoritmo, também é necessária a mesma chave para a descriptografia. Se nenhuma chave for especificada em machineKey, o ASP.NET 2.0 usará uma chave gerada aleatoriamente por padrão. Essa chave aleatória é gerada por System.Web.HttpRuntime.SetAutogenKeys() e armazenada em System.Web.HttpRuntime.s_autogenKeys. esse valor através da reflexão. O machineKey do ASP.NET 1.1 é definido em machine.config e uma chave aleatória também é usada por padrão:
<machineKey validaçãoKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validação="SHA1"/>.
O problema está nas diferentes chaves aleatórias. Se você especificasse a chave no ASP.NET 1.1 original, esse problema não existiria, mas isso geralmente é considerado ao usar Web farms. Geralmente, uma chave aleatória é usada. O ASP.NET irá gerar diferentes chaves aleatórias para diferentes aplicativos. Esse problema de falha de cookie do cliente ocorrerá em muitas situações, como: reinstalar o sistema, mover o aplicativo ASP.NET para outro computador, O aplicativo da web é movido para um diretório virtual diferente. e assim por diante.
Como resolver este problema?
O princípio é muito simples, desde que saibamos o valor da chave gerada aleatoriamente no ASP.NET 1.1 e, em seguida, especifique-o no web.config do aplicativo ASP.NET 2.0. Existem duas chaves aqui: uma é a criptografia. A chave decryptionKey, uma é a chave de cálculo de hash validaçãoKey (para evitar que o cookie seja adulterado no meio do caminho). Se soubermos que as chaves são: X e Y, então em web.config
O problema pode ser resolvido fazendo as seguintes configurações:
<machineKey validaçãoKey="X" decryptionKey="Y" decryption="3DES"/>
O problema é como obter o valor da chave gerada aleatoriamente no ASP.NET 1.1. A chave está armazenada na LSA (Autoridade de Segurança Local do Windows), mas não encontrei uma maneira de obter a chave da LSA.
Como o blog park resolve principalmente o problema de cookies de login, e esse cookie é gerado em System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPersistentCookie), então comecei a partir de System.Web.Security do ASP.NET 1.1 Iniciando com o código-fonte de .FormsAuthentication, descobri System.Web.Configuration.MachineKey. Após pesquisas adicionais sobre o código-fonte de MachineKey, encontrei duas chaves em MachineKeyConfig de MachineKey, que existem nos dois membros estáticos privados de s_validationKey e s_oDes (. Foi preciso muito esforço para descobrir isso), o valor de validaçãoKey é armazenado diretamente em s_validationKey e o decryptionKey é armazenado em s_oDes.Key. Como MachineKey é uma classe interna e MachineKeyConfig é um tipo privado, esses dois membros são membros estáticos privados e não podem ser acessados diretamente. Neste momento, é hora de a poderosa função de reflexão do .NET entrar em ação. Esses dois valores são obtidos por meio de reflexão. Deve-se observar que o tipo desses dois valores é Byte[]. Por meio de testes, verifica-se que a chave gerada pela conversão direta em uma string é inválida. Você precisa chamar System.Web.Configuration.MachineKey.ByteArrayToHexString por meio de reflexão (Byte[], Int32) convertido em string.
Finalmente resolvi esse problema esta noite, tão animado! Eu quis desistir várias vezes no meio, mas pensei que depois que o programa blog park fosse atualizado para ASP.NET 2.0, esse problema causaria problemas para muitas pessoas. Embora eu só precise fazer login novamente, ainda sinto isso. Preciso resolver esse problema e fazer. O desenvolvimento de programas não visa trazer comodidade aos usuários, tanto quanto possível?
A solução deste problema exigirá mais preparativos para a atualização do site Blog Park para ASP.NET 2.0.
Fonte: programador dudu-happy