.NET 3.0에서 3.5로 업그레이드 : 웹 가든에서 발생할 때 StatesErver로 설정된 사이트는 Inproc으로 되돌아갑니다.

StackOverflow https://stackoverflow.com/questions/526697

문제

대본:

.NET 3.0을 실행하는 서버와 웹 정원이 활성화 된 애플리케이션 풀에서 실행되는 ASP.NET 웹 사이트 (프로세스 수 : 3). web.config 구성은 다음과 같습니다.

    <sessionState
      cookieless="UseCookies"
      cookieName=".authz"
      mode="StateServer"
      regenerateExpiredSessionId="true"
      stateConnectionString="tcpip=127.0.0.1:42424"
      timeout="60"
      useHostingIdentity="true" />

이제 기계를 .NET 3.5 SP1로 업그레이드하십시오. 서버를 재부팅하십시오. 결과 : 세션은 더 이상 W3wp.exe의 사례에 걸쳐 유지되지 않습니다. 1 작업자 프로세스로 줄이는 것은 현재 해결 방법입니다.

이상한 점 : 다른 서버의 동일한 코드는 문제가 없습니다. 나는 전에이 문제를 경험했지만 다시 시작한 후 마술처럼 사라졌습니다. 나는 이미 한 번 다시 시작했지만 지금까지는 기쁨이 없습니다.

두 서버의 두 machine.configs 및 web.configs 비교 : 동일합니다.

다른 사람 이이 문제를 경험했습니다, 그러나 거기에 답이 없습니다.

어떤 아이디어? 나는 진짜 이것에 머물 렀습니다.

도움이 되었습니까?

해결책

그래서 이것은 단지 놀랍습니다.

다음 조건이 모두 사실 일 때 문제가 발생하는 것으로 보입니다.

  • Windows Server 2003 (IIS 6.0) 및 ASP.NET 2.0 웹 사이트를 실행 중입니다.
  • 웹 사이트는 최대 작업자 프로세스 수가 1보다 큰 웹 가든을 사용하도록 구성됩니다. 이로 인해 프로세스 외부 세션 스토리지를 사용하도록 응용 프로그램을 구성했습니다. 이 시나리오에서 ASP.NET 상태 서비스는 로컬 컴퓨터에서 실행됩니다.
  • 애플리케이션 풀 ID는 네트워크 서비스가 아니라 귀하가 만든 사용자 정의, 저렴한 사용자 계정으로 설정됩니다. 배포 모범 사례.
  • .NET 프레임 워크를 업데이트하는 설치 프로그램을 실행합니다. 제 경우에는 .NET 3.0에서 .NET 3.5 SP1에서 업데이트되었습니다.

업그레이드가 완료되고 서버를 재부팅 할 때 원래 요청을 제공 한 원래 작업자 프로세스를받을 확률이 3 중 1 분의 1에 불과하기 때문에 페이지를 새로 고칠 때 세션 변수가 자주 손실된다는 것을 알게됩니다. 그러나 ASP.NET 상태 서비스를 사용하고 있기 때문에 이것은 중요하지 않습니다. 무슨 일이 일어 났어?

ASP.NET State Service를 사용할 때 ASP.NET은 machineKey 저장할 모든 세션 데이터를 암호화 및/또는 해시에 저장하려면 (암호화 또는 해싱인지 또는 둘 다인지 모르겠지만이 토론에는 중요한 차이가 아닙니다). 이는 모든 작업자 프로세스가 세션 식별자를 사용하여 서비스의 데이터를 요청할 때 외부 데이터 소스에 저장되는 동안 데이터가 변조되지 않았는지 확인할 수 있습니다.

웹 팜에 있다면 아마도 정적이있을 것입니다. machineKey 당신의 정의 web.config 파일 및이 문제는 발생하지 않습니다. 그러나 단일 서버 웹 정원 시나리오의 경우 아마도 기본값에 의존 할 것입니다. machineKey 설정, 설정 AutoGenerate,IsolateApps ASP.NET 2.0 응용 프로그램의 경우. 즉, ASP.NET은 응용 프로그램 풀에 고유 한 머신 키를 자동으로 생성합니다. 일부 알고리즘에 따라이 키를 재생하지만이 논의에는 중요하지 않습니다.

생성 된 값은 일반적으로 아래의 레지스트리에 저장됩니다. HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}. 그러나 .NET Framework Installer가 잘못 (버그라고 생각합니다)은이 레지스트리 키를 파괴하고 부상에 모욕을 더하기 위해이 키의 권한을 재설정하여 사용자 정의 응용 프로그램 풀 ID가 레지스트리 항목에 쓸 수 없도록이 키의 권한을 재설정합니다. 새 기계 키를 만들려면

그 결과 웹 가든에서 회전하는 각 작업자 프로세스는 제 시간에 생성 된 기계 키의 자체 메모리 사본을 사용하여 우연히 웹 팜 시나리오를 효과적으로 생성합니다. 예를 들어, 작업자가 회전을 처리하고 AutoGenKey 입력이 존재합니다 (실제로는 할 수 없습니다 읽다 IT), 자체 자체를 생성하고 ASP.NET 상태 서비스로 전송 된 해시 데이터를 사용하기 시작합니다. 이 새 기계 키를 레지스트리 항목에 저장하려고하지만 조용히 실패합니다. 작업자 프로세스 B가 회전하고, NO를 본다 AutoGenKey 입력이 존재하고 자체적으로 생성되며 사용을 시작합니다 저것 해시 데이터에 ... 이것이 어디로 가고 있는지 알 수 있습니다.

결과는 이제 세 가지 다른 기계 키로 세션 데이터를 해시했습니다. 세션 식별자의 데이터가 존재하지만, 3 개의 작업자 프로세스 중 2 개는 자체 키를 사용하고 있기 때문에 유효하지 않은/변조로 거부합니다.

당신은 명시 적으로 사용자 정의를 설정함으로써 이것을 둘러 볼 수 있습니다. machineKey 당신의 web.config 파일.

또는 다시 실행할 수 있습니다 aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName 깨진 권한을 수정하기위한 명령 프롬프트에서.

당신의 문제가 해결되었습니다. 잠자리에 갈 시간.

6 월 30 일 업데이트 : 이 문제에 대한 보고서에 따르면 Microsoft Connect, Microsoft는 설치 프로그램을 수정 하여이 동작이 .NET 4로 업그레이드하는 것으로 시작하지 않도록 설치자를 수정했다고 지적했습니다. 미래의 모든 3.0/3.5 업그레이드에서도 여전히 발생할 수 있으므로이 질문/답변을 유지하겠습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top