الترقية من .NET 3.0 إلى 3.5: تعود المواقع إلى ersterver إلى inproc عندما تكون في حديقة الويب

Question

سيناريو:

خذ خادمًا يعمل .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 ، كما لو أن جميعهم عادوا إلى inproc. التخفيض إلى عملية عامل واحد هو الحل الحالي.

ما هو غريب: نفس الرمز على خادم مختلف لا يواجه أي مشاكل. لقد واجهت هذه المشكلة من قبل ، لكنها ذهبت بطريقة سحرية بعد إعادة التشغيل. أعدت تشغيلها مرة واحدة بالفعل ، لكن لا فرح حتى الآن.

مقارنة اثنين من machine.configs و web.configs من الخادمين: متطابقة.

شخص آخر عانى من هذه المشكلة, ، ولكن لا إجابة هناك.

أيه أفكار؟ انا حقًا صامت على هذا واحد.

Answer 1

لذلك ، كان هذا واحد مذهل.

يبدو أن المشكلة تحدث عندما تكون جميع الشروط التالية صحيحة:

• تقوم بتشغيل Windows Server 2003 (IIS 6.0) وموقع ASP.NET 2.0.
• يتم تكوين موقع الويب لاستخدام حدائق الويب ، حيث يكون الحد الأقصى لعدد عمليات العمال أكبر من 1. بسبب هذا ، قمت بتكوين تطبيقك لاستخدام تخزين جلسة خارج العملية ؛ في هذا السيناريو ، تعمل خدمة ASP.NET State على الجهاز المحلي.
• تم تعيين هوية تجمع التطبيق على خدمة الشبكة ولكن لحساب مستخدم مخصص وذات المحرّك الذي قمت بإنشائه لكل نشر أفضل الممارسات.
• يمكنك تشغيل مثبت يقوم بتحديث إطار .NET ؛ في حالتي ، كان هذا تحديثًا من .NET 3.0 إلى .NET 3.5 SP1.

عند الانتهاء من الترقية وإعادة تشغيل الخادم ، تجد أن متغيرات الجلسة الخاصة بك تضيع في كثير من الأحيان عند تحديث الصفحة ، حيث لا يوجد سوى فرصة واحدة في 3 في الحصول على عملية العمال الأصلية التي تخدم طلبك الأصلي. ولكن هذا لا ينبغي أن يهم ، لأنك تستخدم خدمة حالة ASP.NET. ما كسر؟

عند استخدام خدمة حالة ASP.NET ، يستخدم 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 بشكل غير صحيح (أعتقد أن هذا خطأ) يدمر مفتاح التسجيل هذا ، ولإضافة إهانة للإصابة ، يعيد تعيين الأذونات على هذا المفتاح بحيث لا يمكن أن تكتب هوية تجمع التطبيقات المخصصة إلى إدخال التسجيل عندما يذهب لإنشاء مفتاح الجهاز الجديد.

والنتيجة هي أن كل عملية عامل تدور في حديقة الويب تستخدم نسختها الخاصة في الذاكرة من مفتاح الجهاز الذي تم إنشاؤه في الوقت المناسب تمامًا ، وإنشاء سيناريو مزرعة ويب بشكل فعال. على سبيل المثال ، يقوم العامل بمعالجة الدوران ، يرى أن لا AutoGenKey دخول موجود (في الواقع ، لا يمكنه حتى قرأ إنه) ، يولد خاصًا به ويبدأ باستخدام ذلك إلى بيانات التجزئة المرسلة إلى خدمة حالة ASP.NET. يحاول حفظ مفتاح الجهاز الجديد هذا لإدخال التسجيل ، لكنه يفشل بصمت. عملية العمال ب تدور ، ترى أن لا AutoGenKey الإدخال موجود ويولده ويبدأ في استخدام الذي - التي إلى بيانات التجزئة ... ترى إلى أين يحدث هذا.

والنتيجة هي الآن أن لديك بيانات بيانات جلسة مع ثلاثة مفاتيح آلة مختلفة. على الرغم من وجود بيانات معرف الجلسة ، إلا أن اثنتان من أصل ثلاث من عمليات العمال سترفضها على أنها غير صالحة/معبأة لأنها تستخدم مفتاحها الخاص.

يمكنك الالتفاف على هذا من خلال تعيين مخصص بشكل صريح machineKey في الخاص بك web.config ملف.

أو يمكنك إعادة تشغيل aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName في موجه الأوامر لإصلاح الأذونات المكسورة.

تم حل مشكلتك. وقت للذهاب إلى السرير.

---

تحديث 30 يونيو: حسب تقريري عن هذه القضية Microsoft Connect, ، أشارت Microsoft إلى أنها قد أصلحت المثبت بحيث لا يحدث هذا السلوك بدءًا من ترقيات إلى .NET 4. لا يزال يمكن أن يحدث لجميع ترقيات المستقبل 3.0/3.5 ، لذلك سأترك هذا السؤال/الإجابة.