تسجيل الدخول باستخدام حساب Microsoft
سجل الدخول أو أنشئ حسابا.
مرحباً،
حدد حسابا مختلفا.
لديك حسابات متعددة
اختر الحساب الذي تريد تسجيل الدخول باستخدامه.

ما هي حاله العرض ؟

حاله العرض هي المعلومات التي يتم تعثرها الجولة بين صفحات WebForms (.aspx) في تطبيق ASP.NET. علامات HTML للحقل __VIEWSTATE مشابهه لما يلي:

<نوع الإدخال ="مخفي" اسم = "__VIEWSTATE" معرف ="__VIEWSTATE" قيمة ="..." />مثال واحد من العناصر التي قد يتم تخزينها في الحقل __VIEWSTATE هو نص عنصر تحكم زر. إذا قام مستخدم بالنقر فوق الزر، سيتمكن معالج الأحداث Button_Click من استخراج نص الزر من حقل حالة العرض. راجع موضوع "نظرة عامة حول حالة عرض ASP.NET" على موقع شبكة مطوري Microsoft (MSDN) للحصول على نظرة عامة أكثر تفصيلاً عن حالة عرض ASP.NET. لأن الحقل __VIEWSTATE يحتوي على معلومات هامة يتم استخدامها لإعادة إنشاء الصفحة على إعادة النشر، تأكد من أن المهاجم لا يمكن العبث بهذا الحقل. إذا قام مهاجم بإرسال حمولة __VIEWSTATE ضارة، فمن المحتمل أن يقوم المهاجم بخداع التطبيق لتنفيذ إجراء لم يكن ليقوم به لولا ذلك. لمنع هذا النوع من هجوم العبث، يتم حماية الحقل __VIEWSTATE بواسطة رمز مصادقة رسالة (MAC). ASP.NET بالتحقق من صحة MAC التي يتم إرسالها مع حمولة __VIEWSTATE عند حدوث إعادة النشر. يتم تحديد المفتاح المستخدم لحساب MAC في عنصر التطبيق في ملف Web.config. نظرًا لأن المهاجم لا يمكن تخمين محتويات العنصر <machineKey> ، لا يمكن للمهاجم توفير MAC صالح إذا حاول المهاجم العبث بحمولة __VIEWSTATE. سيقوم ASP.NET بالكشف عن عدم توفير MAC صالح، وسوف يرفض ASP.NET الطلب الضار.

ما الذي يسبب أخطاء التحقق من صحة MAC ؟

سيشبه خطأ التحقق من صحة MAC المثال التالي:

خطا خادم في '/' التطبيق. فشل التحقق من صحة حاله العرض MAC. إذا كان هذا التطبيق تتم استضافته بواسطة تكتل ويب أو كتله ، تاكد من ان تكوين < المفتاح > يحدد نفس التحقق من صحة خوارزميه و. لا يمكن استخدام الإنشاء التلقائي في نظام مجموعه. الوصف: حدث استثناء غير معالج اثناء تنفيذ طلب ويب الحالي. الرجاء مراجعه تتبع المكدس للحصول علي مزيد من المعلومات حول الخطا والمكان الذي تم إنشاؤه في التعليمات البرمجية. تفاصيل الاستثناء: النظام. ويب. هتبسيبشن: التحقق من صحة حاله العرض MAC فشل. إذا تم استضافه هذا التطبيق بواسطة تكتل ويب أو كتله ، تاكد من ان التكوين < المفتاح > يحدد نفس التحقق من صحة خوارزميه و. لا يمكن استخدام الإنشاء التلقائي في نظام مجموعه. خطا المصدر: [لا توجد خطوط مصدر ذات صله] الملف المصدر:... الخط: 0 تتبع المكدس: [Viewstate استثناء: حاله عرض غير صالحه. العميل IP::: 1 المنفذ: 40653 المرجع: http://localhost:40643/MyPage.aspx المسار:/ماباجاجيaspx وكيل المستخدم: موزيلا/5.0 (متوافق; MSIE 10.0; Windows NT 6.2; WOW64 ترايدنت/6.0) حاله العرض:...] [هتبسيبشن (0x80004005): فشل التحقق من صحة حاله العرض MAC. إذا تم استضافه هذا التطبيق بواسطة تكتل ويب أو كتله ، تاكد من ان التكوين < المفتاح > يحدد نفس التحقق من صحة خوارزميه و. لا يمكن استخدام الإنشاء التلقائي في نظام مجموعه. راجع http://go.microsoft.com/fwlink/?LinkID=314055 للحصول علي مزيد من المعلومات.] النظام. واجهه المستخدم (استثناء الداخلية ، سلسله بيرسيستيدستاتي ، سلسله errorPageMessage ، القيمة المنطقية Macفاليكاتاتيونرور) + 190 System.Web.UI.فيوستيتاكسسيبشن.رميماتشوفيتيفيووير (استثناء داخلي، سلسلة لا تزال الدولة) +46 System.Web.UI.ObjectStateFormatter.Deserialize (سلسلة إدخال سلسلة، الغرض الغرض) +861 System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize (سلسلة serializedState، الغرض) +51 النظام.Web.UI.Util.DeserializeWithAssert(إيستاتفورماتر2 ماصة، سلسلة serializedState، الغرض الغرض) +67 النظام.ويب.UI.مخفيفيلدبيجستاتبيرسي.تحميل() +444 النظام.ويب.UI.الصفحة.تحميلالدولةمنبرثباتمتوسط() +368 صفحه ويب. واجهه المستخدم. LoadAllState () + 109 System.Web.UI.Page.ProcessRequestMain(منطقية تشملمراحلقبلأنتكونكبوينت، منطقية تشملمراحلبعد AsyncPoint) +7959 System.Web.UI.Page.ProcessRequest(منطقية تشملمراحلقبلالمزامنة، منطقية تشملStagesAfterAsyncPoint) +429 النظام.ويب.UI.الصفحة.عمليةالطلب() +125 System.Web.UI.Page.ProcessRequestWithNoAssert (سياق httpContext) +48 النظام.ويب.UI.Page.ProcessRequest (سياق httpContext) +234 ASP.mypage_aspx. معالجةالطلب (سياق HttpContext) في ...:0 System.Web.CallHandlerExecutionStep.System.Web.httpapplication.IExecutionStep.Execute() +1300 System.Web.HttpApplication.ExecuteStep(خطوة IExecutionStep، منطقية ومكتملة بشكل متزامن) +140

السبب 1: تطبيق ويب قيد التشغيل في مزرعة (بيئة ملقم متعددة)

ASP.NET تلقائيا بإنشاء مفتاح تشفير لكل تطبيق ويخزن المفتاح في خليه التسجيل HKCU. يتم استخدام هذا المفتاح الذي تم إنشاؤه تلقائيا إذا لم يكن هناك عنصر > < المفتاح الصريح في تكوين التطبيق. ومع ذلك ، لان هذا المفتاح الذي تم إنشاؤه تلقائيا محلي إلى الكمبيوتر الذي قام بإنشاء المفتاح ، يؤدي هذا السيناريو مشكله للتطبيقات التي يتم تشغيلها في مزرعة. سيقوم كل ملقم في المزرعة بإنشاء المفتاح المحلي الخاص به ، ولن توافق اي من الملقمات في المزرعة علي المفتاح الذي سيتم استخدامه. والنتيجة هي انه إذا كان ملقم واحد بإنشاء حموله __VIEWSTATE يستهلك ملقم مختلف ، سيواجه المستهلك فشل التحقق من صحة MAC.

  • دقة 1a: إنشاء عنصر صريح <machineKey> عن طريق إضافة عنصر صريح <machineKey> إلى ملف Web.config للتطبيق، يقوم المطور بإعلام ASP.NET بعدم استخدام مفتاح التشفير الذي تم إنشاؤه تلقائيًا. راجع الملحق A للحصول على إرشادات حول كيفية إنشاء عنصر <machineKey> . بعد إضافة هذا العنصر إلى ملف Web.config إعادة نشر التطبيق إلى كل ملقم في المزرعة. ملاحظة تتخذ بعض خدمات استضافة المواقع، مثل مواقع Microsoft Azure على الويب، خطوات لمزامنة المفتاح الذي تم إنشاؤه تلقائيًا لكل تطبيق عبر ملقماتها الخلفية. يتيح هذا للتطبيقات التي لم تحدد عنصر صريح <machineKey> متابعة العمل في هذه البيئات، حتى إذا كان التطبيق قيد التشغيل في مزرعة. إذا كان التطبيق الخاص بك قيد التشغيل على خدمة استضافة من جهة خارجية، يرجى الاتصال بموفر الاستضافة لتحديد ما إذا كان هذا الموقف ينطبق عليك.

  • القرار 1b: تمكين التقارب في موازن التحميل إذا كانت المواقع الخاصة بك تعمل خلف موازن التحميل ، يمكنك تمكين تقارب الخادم للعمل مؤقتا حول المشكلة. يساعد هذا في التاكد من ان اي عميل معين يتفاعل فقط مع ملقم فعلي واحد خلف موازن التحميل بحيث كل حمولات التشفير سيتم إنشاؤها بواسطة نفس الخادم واستهلاكها. وينبغي الا يعتبر ذلك حلا طويل الأجل للمشكلة. حتى عند تمكين تقارب الخادم ، سيقوم معظم موازن التحميل باعاده توجيه العميل إلى خادم فعلي مختلف إذا كان الخادم الأصلي الذي تم تحميله موازن التحميل غير متصل. يؤدي هذا الملقم الجديد لرفض حمولات التشفير (مثل __VISSTATE ، وتذاكر مصادقه النماذج ، والرموز المميزة لمكافحه التزوير MVCs ، والخدمات الأخرى) التي لدي العميل حاليا. يجب ان يفضل استخدام عنصر > < المفتاح الواضح وأعاده نشر التطبيق عبر تمكين تقارب الخادم.

السبب 2: يستخدم العملية المنفذة هوية تجمع التطبيقات IIS 7.0

خدمات معلومات إنترنت (IIS) 7.0 (نظام التشغيل Windows Vista، Windows Server 2008) قدم هوية تجمع التطبيقات، آلية عزل جديدة تساعد على توفير مزيد من الأمان للملقمات التي تقوم بتشغيل ASP.NET التطبيقات. ومع ذلك، ليس لدى المواقع التي يتم تشغيلها ضمن هوية تجمع التطبيقات الوصول إلى التسجيل HKCU. هذا هو المكان الذي يقوم فيه وقت تشغيل ASP.NET بتخزين المفاتيح التي تم إنشاؤها تلقائيًا <machineKey> . والنتيجة هي أنه لا يمكن ASP.NET استمرار المفتاح الذي تم إنشاؤه تلقائيًا عند إعادة تعيين تجمع التطبيقات. لذلك، في كل مرة يتم فيها إعادة تعيين w3wp.exe، يتم إنشاء مفتاح مؤقت جديد. ملاحظة هذه ليست مشكلة في IIS 7.5 (ويندوز 7، Windows Server 2008 R2) والإصدارات الأحدث. على هذه الإصدارات من IIS، يمكن أن تستمر ASP.NET المفاتيح التي تم إنشاؤها تلقائيًا في موقع مختلف الذي ينجو من إعادة تعيين تجمع التطبيقات.

  • القرار 2a: استخدام الأداة المساعدة aspnet_regiis تحتوي ASP.NET التثبيتات على أداة مساعدة aspnet_regiis.exe. تتيح هذه الأداة المساعدة ASP.NET واجهة مع IIS لتنفيذ التكوينات المطلوبة لتشغيل تطبيق مدار. يقوم أحد هذه التكوينات بإنشاء المفاتيح الضرورية في خلية التسجيل لتمكين استمرارية مفاتيح الجهاز التي تم إنشاؤها تلقائيًا. أولاً، يجب عليك تحديد تجمع التطبيقات الذي يستخدمه موقعك. يمكن تحديد هذا باستخدام الأداة المساعدة inetmgr المضمنة مع IIS. حدد موقعك في طريقة العرض الشجري على اليسار، وانقر بزر الماوس الأيمن فوق إدارة Website، ثم انقر فوق إعدادات متقدمة. سيظهر مربع الحوار الذي يظهر اسم تجمع التطبيقات. إعدادات متقدمة سقالة مفاتيح التسجيل المناسبة لتجمع تطبيقات 4.0 ASP.NET اتبع الخطوات التالية:

    1. افتح موجه أوامر اداريه.

    2. حدد موقع الدليل المناسب استناداً إلى ما إذا كان تجمع التطبيقات 32 بت أو 64 بت:

      • 32-بت تجمع التطبيقات: cd/d%windir%\Microsoft.NET\Framework\v4.0.30319

      • تجمع التطبيقات 64 بت: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

    3. الانتقال إلى الدليل، اكتب الأمر التالي، ثم اضغط مفتاح الإدخال Enter:

      aspnet_regiis-ga "IIS APPPOOL\app-pool-name"

    إذا كان تجمع التطبيقات تجمع تطبيقات ASP.NET 2.0 أو 3.5 اتبع الخطوات التالية:

    1. افتح موجه أوامر اداريه.

    2. حدد موقع الدليل المناسب استنادا إلى ما إذا كان تجمع التطبيقات الخاص بك هو 32 بت أو 64 بت:

      • تجمع التطبيقات 32 بت: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727

      • تجمع التطبيقات 64 بت: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. الانتقال إلى الدليل، اكتب الأمر التالي، ثم اضغط مفتاح الإدخال Enter:

      aspnet_regiis-ga "IIS APPPOOL\app-pool-name"

    علي سبيل المثال ، إذا تم تسميه تجمع التطبيقات الخاص بي "تجمع التطبيقات " (كما في الصورة السابقة) ، قم بتشغيل الأمر التالي:

    aspnet_regiis "IIS APPPOOL\My التطبيق تجمع" ملاحظة خدمات النظام APPHOSTSVC و WAS قد يكون قيد التشغيل للأداة المساعدة aspnet_regiis لحل أسماء IIS APPPOOL\* بشكل مناسب.

  • الدقة 2b: إنشاء عنصر صريح <machineKey> عن طريق إضافة عنصر صريح <machineKey> إلى ملف Web.config للتطبيق، يقوم المطور بإعلام ASP.NET بعدم استخدام مفتاح التشفير الذي تم إنشاؤه تلقائيًا. راجع الملحق A للحصول على إرشادات حول كيفية إنشاء عنصر <machineKey> .

السبب 3: يتم تكوين تجمع التطبيقات باستخدام LoadUserProfile = خطا

إذا كان تجمع التطبيقات قيد التشغيل مع هويه مخصصه ، قد لا يكون IIS تحميل ملف تعريف المستخدم للهوية. وهذا له التاثير الجانبي لجعل التسجيل HKCU غير متوفر ل ASP.NET للاستمرار في < > المفتاح الذي تم إنشاؤه تلقائيا. لذلك ، سيتم إنشاء مفتاح إنشاء تلقائي جديد كل مره يتم فيها أعاده تشغيل التطبيق. راجع قسم " ملف تعريف المستخدم " علي موقع Microsoft علي ويب للحصول علي مزيد من المعلومات.

  • القرار 3a: استخدام الاداه المساعدة aspnet_regiis الإرشادات الخاصة بهذا هي نفس القرار 2 ا. راجع هذا المقطع للحصول علي مزيد من المعلومات.

  • القرار 3b: استخدام مفتاح < المحددة > بواسطة أضافه عنصر > < الاساسيه الصريحة إلى ملف web.config الخاص بالتطبيق ، يخبر المطور ASP.NET بعدم استخدام مفتاح التشفير الذي تم إنشاؤه تلقائيا. راجع الملحق a للحصول علي إرشادات حول كيفيه إنشاء عنصر > < المفتاح.

  • القرار 3c: توفير مفاتيح التسجيل HKCU المطلوبة يدويا إذا كان لا يمكنك تشغيل الاداه المساعدة aspnet_regiis يمكنك استخدام برنامج نصي Windows PowerShell لتوفير مفاتيح التسجيل المناسبة في HKCU. انظر التذييل باء للحصول علي مزيد من المعلومات.

  • القرار 3d: تعيين LoadUserProfile = صواب لتجمع التطبيقات هذا يمكنك أيضا تمكين تحميل ملف تعريف المستخدم داخل تجمع التطبيقات هذا. وهذا يجعل خليه التسجيل HKCU والمجلد المؤقت ومواقع التخزين الخاصة بالمستخدم الأخرى المتوفرة للتطبيق. ومع ذلك ، قد يؤدي هذا إلى زيادة استخدام القرص أو الذاكرة للعملية المنفذة. راجع العنصر للحصول علي مزيد من المعلومات حول كيفيه تمكين هذا الاعداد.

السبب 4: الخاصية الصفحة. Viewdata Userkey قيمه غير صحيحه

يمكن لمطوري البرامج ان يقرروا استخدام الصفحة. Viewstate Userkey الخاصية لأضافه حماية التزوير طلب المواقع المشتركة إلى الحقل __VIEWSTATE. إذا كنت تستخدم الخاصية Viewdata Userkey ، يتم تعيينها عاده إلى قيمه مثل اسم المستخدم الحالي أو معرف جلسة عمل المستخدم. قوالب المشروع لتطبيقات WebForms في Microsoft Visual Studio 2012 والإصدارات الأحدث تحتوي على نماذج تستخدم هذه الخاصية. راجع الموضوع الخاصية Page.ViewStateUserKey على موقع شبكة مطوري Microsoft (MSDN) للحصول على مزيد من المعلومات. إذا تم تحديد الخاصية فيوستيتوسيركي، يتم نسخ قيمته في __VIEWSTATE في وقت الإنشاء. عند استهلاك الحقل __VIEWSTATE، يتحقق الملقم من الخاصية ViewStateUserKey الصفحة الحالية ويقوم بالتحقق من صحة ذلك مقابل القيمة التي تم استخدامها لإنشاء الحقل __VIEWSTATE. إذا لم تتطابق القيم، يتم رفض الطلب كاحتمال ضار. مثال على فشل فيوستيتوسيركي ذات الصلة سيكون عميل الذي لديه اثنين من علامات التبويب المفتوحة في المستعرض. يتم تسجيل العميل في ك المستخدم ا ، وفي علامة التبويب الاولي ، يتم تقديم الصفحة مع __VIEWSTATE الخاصية Viewstate Userkey التي تحتوي علي "المستخدم ا." في علامة التبويب الثانية، العميل بتسجيل الخروج ومن ثم تسجيل الدخول مرة أخرى كمستخدم ب. يعود العميل إلى علامة التبويب الأولى ويقوم بإرسال النموذج. قد تحتوي الخاصية فيوستاتيوسيركي على "المستخدم ب" (لأن هذا هو ما يقول ملف تعريف ارتباط مصادقة العميل). ومع ذلك، يحتوي الحقل __VIEWSTATE الذي قام العميل المرسلة على "المستخدم A." يؤدي عدم التطابق هذا الفشل.

  • القرار 4a: تحقق من ان Viewستاتيوسيركي يتم تعيين بشكل صحيح إذا كان التطبيق الخاص بك يستخدم الخاصية Viewstate Userkey ، تحقق من ان قيمه الخاصية هي نفسها عند إنشاء حاله العرض وعند استهلاكها. إذا كنت تستخدم اسم مستخدم تسجيل الدخول الحالي ، تاكد من ان المستخدم لا يزال تسجيل الدخول وان هويه المستخدم لم تتغير في وقت أعاده النشر. إذا كنت تستخدم معرف جلسة عمل المستخدم الحالي ، تاكد من ان جلسة العمل لم انتهت مهله. إذا كنت تقوم بتشغيل في بيئة مزرعة تاكد من تطابق عناصر < المفتاح >. راجع الملحق A للحصول علي إرشادات حول كيفيه إنشاء هذه العناصر.

الملحق A: كيفيه إنشاء عنصر > < المفتاح

تحذير أمني هناك العديد من مواقع الويب التي ستقوم بإنشاء عنصر <machineKey> لك بنقرة زر واحدة. أبدا استخدام عنصر < المفتاح > الذي حصلت عليه من أحد هذه المواقع. من المستحيل معرفة ما إذا كانت هذه المفاتيح قد تم إنشاؤها بشكل آمن أو إذا تم تسجيلها إلى قاعدة بيانات سرية. يجب عليك فقط استخدام عناصر التكوين <machineKey> التي قمت بإنشائها بنفسك.

لإنشاء عنصر <machineKey> بنفسك، يمكنك استخدام البرنامج النصي لـ Windows PowerShell التالي:

# Generates a <machineKey> element that can be copied + pasted into a Web.config file.
function Generate-MachineKey {
  [CmdletBinding()]
  param (
    [ValidateSet("AES", "DES", "3DES")]
    [string]$decryptionAlgorithm = 'AES',
    [ValidateSet("MD5", "SHA1", "HMACSHA256", "HMACSHA384", "HMACSHA512")]
    [string]$validationAlgorithm = 'HMACSHA256'
  )
  process {
    function BinaryToHex {
        [CmdLetBinding()]
        param($bytes)
        process {
            $builder = new-object System.Text.StringBuilder
            foreach ($b in $bytes) {
              $builder = $builder.AppendFormat([System.Globalization.CultureInfo]::InvariantCulture, "{0:X2}", $b)
            }
            $builder
        }
    }
    switch ($decryptionAlgorithm) {
      "AES" { $decryptionObject = new-object System.Security.Cryptography.AesCryptoServiceProvider }
      "DES" { $decryptionObject = new-object System.Security.Cryptography.DESCryptoServiceProvider }
      "3DES" { $decryptionObject = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider }
    }
    $decryptionObject.GenerateKey()
    $decryptionKey = BinaryToHex($decryptionObject.Key)
    $decryptionObject.Dispose()
    switch ($validationAlgorithm) {
      "MD5" { $validationObject = new-object System.Security.Cryptography.HMACMD5 }
      "SHA1" { $validationObject = new-object System.Security.Cryptography.HMACSHA1 }
      "HMACSHA256" { $validationObject = new-object System.Security.Cryptography.HMACSHA256 }
      "HMACSHA385" { $validationObject = new-object System.Security.Cryptography.HMACSHA384 }
      "HMACSHA512" { $validationObject = new-object System.Security.Cryptography.HMACSHA512 }
    }
    $validationKey = BinaryToHex($validationObject.Key)
    $validationObject.Dispose()
    [string]::Format([System.Globalization.CultureInfo]::InvariantCulture,
      "<machineKey decryption=`"{0}`" decryptionKey=`"{1}`" validation=`"{2}`" validationKey=`"{3}`" />",
      $decryptionAlgorithm.ToUpperInvariant(), $decryptionKey,
      $validationAlgorithm.ToUpperInvariant(), $validationKey)
  }
}

بالنسبة لتطبيقات ASP.NET 4.0، يمكنك فقط استدعاء إنشاء MachineKey بدون معلمات لإنشاء عنصر <machineKey> كما يلي:

PS> Generate-MachineKey
<machineKey decryption="AES" decryptionKey="..." validation="HMACSHA256" validationKey="..." />

ASP.NET 2.0 و 3.5 لا تدعم تطبيقات HMACSHA256. بدلاً من ذلك، يمكنك تحديد SHA1 لإنشاء عنصر متوافق <machineKey> كما يلي:

PS> Generate-MachineKey -validation sha1
<machineKey decryption="AES" decryptionKey="..." validation="SHA1" validationKey="..." />

بمجرد أن يكون لديك عنصر <machineKey> ، يمكنك وضعه في ملف Web.config. العنصر <machineKey> صالح فقط في ملف Web.config في جذر التطبيق الخاص بك وهو غير صالح على مستوى المجلد الفرعي.

<configuration>
  <system.web>
    <machineKey ... />
  </system.web>
</configuration>

للحصول على قائمة كاملة من الخوارزميات المعتمدة، قم بتشغيل تعليمات إنشاء MachineKey من موجه Windows PowerShell.

التذييل باء: توفير السجل لاستمرار المفاتيح التي تم إنشاؤها تلقائيًا

بشكل افتراضي ، لأنه يتم دائما المفاتيح التي تم إنشاؤها تلقائيا في التسجيل HKCU ، قد يتم فقدان هذه المفاتيح إذا لم يتم تحميل ملف تعريف المستخدم في العملية المنفذة IIS ثم بتدوير تجمع التطبيقات. قد يؤثر هذا السيناريو علي موفري الاستضافة المشتركة التي تقوم بتشغيل تجمعات التطبيقات كحسابات مستخدم Windows القياسية. للتغلب علي هذه الحالة ، ASP.NET تمكين استمرار المفاتيح التي تم إنشاؤها تلقائيا في التسجيل HKLM بدلا من التسجيل HKCU. يتم تنفيذ هذا عاده باستخدام الاداه المساعدة aspnet_regiis (راجع الإرشادات الواردة في القسم "القرار 2 ا: استخدام الاداه المساعدة aspnet_regiis"). ومع ذلك ، بالنسبة للمسؤولين الذين لا يريدون تشغيل هذه الاداه المساعدة ، قد يتم استخدام البرنامج النصي Windows PowerShell التالية بدلا من ذلك:

# Provisions the HKLM registry so that the specified user account can persist auto-generated machine keys.
function Provision-AutoGenKeys {
  [CmdletBinding()]
  param (
    [ValidateSet("2.0", "4.0")]
    [Parameter(Mandatory = $True)]
    [string] $frameworkVersion,
    [ValidateSet("32", "64")]
    [Parameter(Mandatory = $True)]
    [string] $architecture,
    [Parameter(Mandatory = $True)]
    [string] $upn
  )
  process {
    # We require administrative permissions to continue.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "This cmdlet requires Administrator permissions."
        return
    }
    # Open HKLM with an appropriate view into the registry
    if ($architecture -eq "32") {
        $regView = [Microsoft.Win32.RegistryView]::Registry32;
    } else {
        $regView = [Microsoft.Win32.RegistryView]::Registry64;
    }
    $baseRegKey = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $regView)
    # Open ASP.NET base key
    if ($frameworkVersion -eq "2.0") {
        $expandedVersion = "2.0.50727.0"
    } else {
        $expandedVersion = "4.0.30319.0"
    }
    $aspNetBaseKey = $baseRegKey.OpenSubKey("SOFTWARE\Microsoft\ASP.NET\$expandedVersion", $True)
    # Create AutoGenKeys subkey if it doesn't already exist
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Get the SID for the user in question, which will allow us to get his AutoGenKeys subkey
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # SYSTEM, ADMINISTRATORS, and the target SID get full access
    $regSec = New-Object System.Security.AccessControl.RegistrySecurity
    $regSec.SetSecurityDescriptorSddlForm("D:P(A;OICI;GA;;;SY)(A;OICI;GA;;;BA)(A;OICI;GA;;;$sid)")
    $userAutoGenKey = $autoGenBaseKey.OpenSubKey($sid, $True)
    if ($userAutoGenKey -eq $null) {
        # Subkey didn't exist; create and ACL appropriately
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Subkey existed; make sure ACLs are correct
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

يوضح المثال التالي كيفية توفير إدخالات التسجيل HKLM المناسبة لتجمع تطبيقات الذي يتم تشغيله كمستخدم example@contoso.com (هذا هو UPN حساب مستخدم Windows). تجمع التطبيقات هذا هو تجمع تطبيقات 32-بت الذي يقوم بتشغيل clr v2.0 (ASP.NET 2.0 أو 3.5).

PS> Provision-AutoGenKeys -FrameworkVersion 2.0 -Architecture 32 -UPN "example@contoso.com"

إذا كان تجمع التطبيقات بدلاً من ذلك تجمع تطبيقات 64-بت الذي يقوم بتشغيل CLR v4.0 (ASP.NET 4.0 أو 4.5) ، الأمر كما يلي:

PS> Provision-AutoGenKeys -FrameworkVersion 4.0 -Architecture 64 -UPN "example@contoso.com"

علي الرغم من ان يتم تخزين المفاتيح التي تم إنشاؤها تلقائيا في HKLM ، يتم أضافه مفتاح التسجيل الفرعي الذي يحتوي علي كل المواد المشفرة السرية لحساب المستخدم إلى قائمه التحكم بالوصول (ACL) بحيث لا يمكن قراءه مواد التشفير بواسطة حسابات المستخدمين الآخرين.

الملحق C: تشفير العنصر > < المفتاح في ملفات التكوين

قد لا يرغب مسؤولو الخادم في المعلومات الحساسة للغاية مثل المادة الرئيسية < المفتاح > إلى النموذج النص العادي في ملفات التكوين. إذا كانت هذه هي الحالة ، قد يقرر المسؤولون الاستفادة من ميزه .NET framework المعروفة باسم "التكوين المحمي". تتيح لك هذه الميزة تشفير مقاطع معينه من ملفات .config. إذا تم الكشف عن محتويات ملفات التكوين هذه من اي وقت مضي ، محتويات هذه المقاطع ستظل سريه. يمكنك العثور علي نظره عامه موجزه عن التكوين المحمي علي موقع MSDN علي ويب. كما انه يحتوي علي برنامج تعليمي حول كيفيه حماية العناصر ال<ه كونيكتكوينسترينج > و < مفتاح > لملف web.config.

هل تحتاج إلى مزيد من المساعدة؟

توسيع المهارات
استكشاف التدريب
الحصول على الميزات الجديدة أولاً
الانضمام إلى Microsoft Insider

هل كانت المعلومات مفيدة؟

ما مدى رضاك عن جودة اللغة؟
ما الذي أثّر في تجربتك؟

نشكرك على ملاحظاتك!

×