عندما تستعد لترقية تطبيق الويب الخاص بك من 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 خوارزمية جديدة ومفتاحًا لفك تشفير ملف تعريف الارتباط الذي أرسله العميل، مما يؤدي إلى عدم صلاحية ملفات تعريف الارتباط في أسب.نت 2.0. في ASP.NET 1.1، يتم استخدام خوارزمية 3DES لتشفير محتوى ملف تعريف الارتباط، بينما في ASP.NET 2.0، يتم استخدام خوارزمية المعايير المشفرة المتقدمة (AES) افتراضيًا لفك التشفير، وهذا أحد أسباب المشكلة يمكنك استخدام الإعدادات المقابلة لتغيير خوارزمية تشفير ملفات تعريف الارتباط في ASP.NET 2.0 إلى 3DES، ما عليك سوى إضافة: <machineKey decryption="3DES"/> إلى web.config. ولكن بعد القيام بذلك، لا تزال المشكلة موجودة، لأنه بالإضافة إلى نفس الخوارزمية، فإن نفس المفتاح مطلوب أيضًا لفك التشفير. إذا لم يتم تحديد أي مفتاح في MachineKey، فسيستخدم ASP.NET 2.0 مفتاحًا تم إنشاؤه عشوائيًا بشكل افتراضي. يتم إنشاء هذا المفتاح العشوائي بواسطة System.Web.HttpRuntime.SetAutogenKeys() ويتم تخزينه في System.Web.HttpRuntime.s_autogenKeys هذه القيمة من خلال التفكير. تم تعيين MachineKey لـ ASP.NET 1.1 في Machine.config، ويتم استخدام مفتاح عشوائي أيضًا بشكل افتراضي:
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>.
تكمن المشكلة في المفاتيح العشوائية المختلفة. إذا قمت بتحديد المفتاح في ASP.NET 1.1 الأصلي، فلن تكون هذه المشكلة موجودة، ولكن يتم أخذ ذلك في الاعتبار بشكل عام عند استخدام مزارع الويب. لذلك عادة ما يتم استخدام مفتاح عشوائي. سيقوم ASP.NET بإنشاء مفاتيح عشوائية مختلفة لتطبيقات مختلفة، وستحدث مشكلة فشل ملف تعريف ارتباط العميل في العديد من المواقف، مثل: إعادة تثبيت النظام، ونقل تطبيق ASP.NET إلى كمبيوتر آخر، ونقل تطبيق الويب إلى دليل ظاهري مختلف. وهكذا.
كيفية حل هذه المشكلة؟
المبدأ بسيط للغاية، طالما أننا نعرف قيمة المفتاح الذي تم إنشاؤه عشوائيًا في ASP.NET 1.1، ثم نحدده في web.config لتطبيق ASP.NET 2.0. هناك مفتاحان هنا: أحدهما هو التشفير مفتاح فك التشفير، أحدهما هو مفتاح التحقق من صحة مفتاح حساب التجزئة (لمنع التلاعب بملف تعريف الارتباط في منتصف الطريق). إذا علمنا أن المفاتيح هي: X و Y، ثم في web.config
يمكن حل المشكلة عن طريق إجراء الإعدادات التالية:
<machineKey validationKey='X' decryptionKey='Y' decryption='3DES'/>
تكمن المشكلة في كيفية الحصول على قيمة المفتاح الذي تم إنشاؤه عشوائيًا في ASP.NET 1.1. يتم تخزين المفتاح في LSA (سلطة الأمان المحلية لـ Windows)، لكنني لم أجد طريقة للحصول على المفتاح من LSA.
نظرًا لأن حديقة المدونات تحل بشكل أساسي مشكلة ملفات تعريف الارتباط لتسجيل الدخول، ويتم إنشاء ملف تعريف الارتباط هذا في System.Web.Security.FormsAuthentication.SetAuthCookie(string userName, bool createPersistentCookie)، لذلك بدأت من System.Web.Security لـ ASP.NET 1.1 بدءًا من باستخدام الكود المصدري لـ .FormsAuthentication، اكتشفت System.Web.Configuration.MachineKey. وبعد إجراء مزيد من البحث حول الكود المصدري لـ MachineKey، وجدت مفتاحين في MachineKeyConfig، الموجودان في العضوين الثابتين الخاصين s_validationKey وs_oDes. لقد استغرق الأمر الكثير من الجهد لاكتشاف ذلك)، ويتم تخزين قيمة validationKey مباشرة في s_validationKey، ويتم تخزين مفتاح فك التشفير في s_oDes.Key. نظرًا لأن MachineKey هي فئة داخلية وMachineKeyConfig هو نوع خاص، فإن هذين العضوين عضوان ثابتان خاصان ولا يمكن الوصول إليهما مباشرة. في هذا الوقت، حان الوقت لبدء تشغيل وظيفة الانعكاس القوية في .NET. يتم الحصول على هاتين القيمتين من خلال الانعكاس، وتجدر الإشارة إلى أن نوع هاتين القيمتين هو Byte[]. ومن خلال الاختبار، وجد أن المفتاح الناتج عن تحويله مباشرة إلى سلسلة غير صالح. تحتاج إلى استدعاء System.Web.Configuration.MachineKey.ByteArrayToHexString من خلال الانعكاس (Byte[]، Int32) الذي تم تحويله إلى سلسلة.
لقد قمت أخيرًا بحل هذه المشكلة الليلة، وأنا متحمس جدًا! أردت الاستسلام عدة مرات في المنتصف، لكنني اعتقدت أنه بعد ترقية برنامج حديقة المدونات إلى ASP.NET 2.0، ستسبب هذه المشكلة مشكلة للعديد من الأشخاص، على الرغم من أنني بحاجة فقط إلى تسجيل الدخول مرة أخرى، إلا أنني ما زلت أشعر بذلك أحتاج إلى حل هذه المشكلة وأليس المقصود من تطوير البرنامج هو توفير الراحة للمستخدمين قدر الإمكان؟
سيؤدي حل هذه المشكلة إلى إجراء المزيد من الاستعدادات لترقية موقع Blog Park على الويب إلى ASP.NET 2.0.
المصدر: مبرمج دودو سعيد