أسماء مستخدمين مؤهّلة بالنطاق في بيانات اعتماد البروكسي
ميّز اسم الحساب غير الشفاف عن واجهات API التي تفصل حقل النطاق، وتجنّب تغيير هوية الحساب لمجرد إرضاء صياغة عنوان URL.
يقول جواب واحد إن عليك إزالة DOMAIN\. ويقول آخر إن عليك إضافته. وكلتا التغييرتين قد تكون خاطئة لبروكسيك.
هناك سؤالان: أي هوية تتوقعها الخدمة، وكيف تمثّل واجهة API المختارة تلك الهوية.
| الواجهة | ما يجب تحديده |
|---|---|
| حقل واحد لاسم الحساب | صيغة الحساب الدقيقة التي يقبلها المشغّل |
| واجهة API لبيانات الاعتماد مع حقل نطاق | هل ينبغي تقديم النطاق واسم المستخدم منفصلين |
| مكوّنات بيانات الاعتماد داخل URI | كيف يجب ترميز القيم المقصودة لذلك الحاوي |
على سبيل المثال، يوفّر .NET مُنشئ NetworkCredential بوسائط منفصلة لاسم المستخدم وكلمة المرور والنطاق. ووضع النطاق في حقلين دون تمييز ليس طريقة محمولة لتهيئة المصادقة المتكاملة.
المصادقة الأساسية حالة أخرى: يفسّر الخادم نص الحساب المقدَّم وفق سياسيته. وكونك على الشبكة نفسها لا يثبت أن بادئة النطاق مضمرة. كما أن الاسم المؤهّل بالنطاق ليس تلقائياً بروتوكول مصادقة مختلفاً.
ينبغي أن يحافظ تهريب عنوان URL على الحساب المقصود لا أن يغيّره. فالشريط العكسي في نص بلغة المصدر، والشريط العكسي في اسم حساب، وتمثيله بالمئة داخل URI طبقات منفصلة.
احصل على صيغة الهوية والمخطط المقبولين من المشغّل، ثم استخدم واجهة بيانات الاعتماد المناسبة. والتناوب العشوائي بين اسم قصير واسم نطاق واسم يشبه البريد الإلكتروني ينتج أدلة ضعيفة بشأن 407 الأصلي.