웹 응용 프로그램을 ASP.NET 1.1에서 ASP.NET 2.0으로 업그레이드하려고 준비할 때 쿠키 문제에 직면하게 됩니다. 클라이언트가 ASP.NET 1.1 응용 프로그램에 저장한 모든 쿠키가 유효하지 않게 됩니다.
Blog Park에서도 이러한 문제가 발생했습니다. Blog Park의 경우 쿠키를 사용하는 모든 사용자가 다시 로그인해야 함을 의미합니다. 이는 큰 문제는 아니지만 비밀번호를 잊어버리면 모든 사람에게 문제가 발생합니다. 더 귀찮아.
사용자 만족을 매우 중요하게 생각하는 웹사이트에서는 이 문제를 해결하기 위한 노력이 필요합니다. 블로그파크는 업그레이드로 인한 영향을 최대한 줄이고자 이 문제에 대해 지난 이틀 동안 연구를 했고 해결책을 찾았습니다.
문제의 원인은 프로그램이 ASP.NET 1.1에서 ASP.NET 2.0으로 업그레이드될 때 ASP.NET 2.0이 새로운 알고리즘과 키를 사용하여 클라이언트가 보낸 쿠키의 암호를 해독하므로 쿠키가 유효하지 않다는 것입니다. ASP.NET 2.0. ASP.NET 1.1에서는 쿠키 내용을 암호화하는 데 3DES 알고리즘이 사용되는 반면, ASP.NET 2.0에서는 AES(Advanced Encrypted Standards) 알고리즘을 기본적으로 사용하여 암호를 해독하는 것이 문제의 원인 중 하나입니다. 해당 설정을 사용하여 ASP.NET 2.0의 쿠키 암호화 알고리즘을 3DES로 변경하려면 web.config에 <machineKey decryption="3DES"/>를 추가하면 됩니다. 그러나 이 작업을 수행한 후에도 문제는 여전히 존재합니다. 왜냐하면 동일한 알고리즘 외에도 암호 해독을 위해 동일한 키가 필요하기 때문입니다. machineKey에 키가 지정되지 않은 경우 ASP.NET 2.0은 기본적으로 무작위로 생성된 키를 사용합니다. 이 임의의 키는 System.Web.HttpRuntime.SetAutogenKeys()에 의해 생성되고 System.Web.HttpRuntime.s_autogenKeys에 저장됩니다. 이 값은 반사를 통해 이루어집니다. ASP.NET 1.1의 machineKey는 machine.config에 설정되어 있으며 기본적으로 임의의 키도 사용됩니다.
<machineKey 유효성 검사Key="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" 유효성 검사="SHA1"/>.
문제는 다른 임의의 키에 있습니다. 원래 ASP.NET 1.1에서 키를 지정했다면 이런 문제는 발생하지 않았을 것이지만, 웹팜을 사용할 때 일반적으로 고려되는 문제입니다. 따라서 일반적으로 임의의 키가 사용됩니다. ASP.NET은 다양한 응용 프로그램에 대해 서로 다른 임의 키를 생성합니다. 이 클라이언트 쿠키 오류 문제는 시스템 재설치, ASP.NET 응용 프로그램을 다른 컴퓨터로 이동, 웹 응용 프로그램이 다른 가상 디렉터리로 이동 등 다양한 상황에서 발생합니다. 등.
이 문제를 해결하는 방법은 무엇입니까?
원칙은 매우 간단합니다. ASP.NET 1.1에서 무작위로 생성된 키의 값을 알고 ASP.NET 2.0 응용 프로그램의 web.config에 지정하면 여기에는 두 개의 키가 있습니다. 하나는 암호화입니다. 키 decryptionKey 중 하나는 해시 계산 키인 ValidationKey입니다(쿠키가 중간에 변조되는 것을 방지하기 위함). 키가 X와 Y라는 것을 알고 있다면 web.config에 있습니다.
다음 설정을 수행하면 문제를 해결할 수 있습니다.
<machineKey 유효성 검사Key="X" decryptionKey="Y" decryption="3DES"/>
문제는 ASP.NET 1.1에서 임의로 생성된 키의 값을 가져오는 방법입니다. 키는 LSA(Windows Local Security Authority)에 저장되어 있는데 LSA에서 키를 가져올 수 있는 방법을 찾지 못했습니다.
블로그 파크에서는 주로 로그인 쿠키 문제를 해결하고 있고 이 쿠키는 System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPertantCookie)에서 생성되므로 ASP.NET 1.1의 System.Web.Security부터 시작했습니다. .FormsAuthentication의 소스 코드를 사용하여 System.Web.Configuration.MachineKey를 발견했습니다. MachineKey의 소스 코드를 추가로 조사한 후 s_validationKey 및 s_oDes의 두 개인 정적 멤버에 존재하는 MachineKey의 MachineKeyConfig에서 두 개의 키를 발견했습니다. 이를 발견하는 데 많은 노력이 필요했습니다.) ValidationKey의 값은 s_validationKey에 직접 저장되고 decryptionKey는 s_oDes.Key에 저장됩니다. MachineKey는 내부 클래스이고 MachineKeyConfig는 비공개 유형이므로 해당 두 멤버는 비공개 정적 멤버이며 직접 액세스할 수 없습니다. 이제 .NET의 강력한 리플렉션 기능이 작동할 차례입니다. 이 두 값은 리플렉션을 통해 얻은 값인데, 이 두 값의 타입이 Byte[]라는 점을 테스트를 통해 직접 문자열로 변환하여 생성한 키가 유효하지 않은 것으로 확인되었습니다. 문자열로 변환된 리플렉션(Byte[], Int32)을 통해 System.Web.Configuration.MachineKey.ByteArrayToHexString을 호출해야 합니다.
오늘 밤 드디어 이 문제를 해결했어요. 너무 신났어요! 중간에 몇번 포기하고 싶었지만 블로그파크 프로그램이 ASP.NET 2.0으로 업그레이드된 이후에는 이 문제로 인해 많은 분들이 불편을 겪게 되리라 생각했습니다. 이 문제를 해결해야 하는데 프로그램 개발은 최대한 사용자에게 편의를 제공하는 것이 아닌가?
이 문제를 해결하면 Blog Park 웹 사이트를 ASP.NET 2.0으로 업그레이드하기 위한 추가 준비가 이루어집니다.
출처 : dudu-happyprogrammer