نام‌های کاربری واجد دامنه در اعتبارنامه‌های پروکسی
نام حساب مبهم را از APIهایی با فیلدهای جداگانه دامنه تشخیص دهید و از تغییر هویت حساب فقط برای برآوردن نحو URL بپرهیزید.
یک پاسخ می‌گوید DOMAIN\ را حذف کنید. پاسخ دیگر می‌گوید آن را اضافه کنید. هر دو تغییر می‌توانند برای پروکسی شما نادرست باشند.
دو پرسش وجود دارد: سرویس چه هویتی را انتظار دارد و API انتخاب‌شده آن هویت را چگونه بازنمایی می‌کند.
| رابط | چه چیزی را باید روشن کرد |
|---|---|
| یک فیلد واحد نام حساب | نحو دقیق حسابی که اپراتور می‌پذیرد |
| API اعتبارنامه با فیلد دامنه | آیا دامنه و نام کاربری باید جداگانه ارائه شوند |
| اجزای اعتبارنامه درون URI | مقادیر موردنظر چگونه باید برای آن ظرف کدگذاری شوند |
برای نمونه، .NET سازنده NetworkCredential را با آرگومان‌های جداگانه نام کاربری، گذرواژه و دامنه ارائه می‌کند. قرار دادن دامنه در دو فیلد بدون تمایز، روشی قابل حمل برای پیکربندی احراز هویت یکپارچه نیست.
احراز هویت Basic مورد دیگری است: سرور متن حساب ارائه‌شده را بر پایه سیاست خودش تفسیر می‌کند. بودن در همان شبکه اثبات نمی‌کند که پیشوند دامنه تلویحی است. همچنین نام واجد دامنه به‌طور خودکار پروتکل احراز هویت متفاوتی نیست.
فرار URL باید حساب موردنظر را حفظ کند نه اینکه آن را تغییر دهد. یک خط مورب برگشتی در رشته‌ای از زبان مبدأ، یک خط مورب برگشتی در نام حساب و نمایش درصدی‌کدشده آن درون URI لایه‌های جداگانه‌اند.
شکل هویت و طرح پذیرفته‌شده را از اپراتور بگیرید، سپس از رابط اعتبارنامه متناظر استفاده کنید. جابه‌جایی تصادفی میان نام کوتاه، نام دامنه و نامی شبیه ایمیل، شواهد ضعیفی درباره 407 اصلی می‌سازد.