په پراکسي اسنادو کې د ډومېن سره سمون لرونکي کارن نومونه
د ناڅرګند حساب نوم له هغو API وو توپیر کړئ چې جلا ډومېن ساحې لري، او یوازې د URL د جملې د پوره کولو لپاره د حساب هویت بدلولو څخه ډډه وکړئ.
یو ځواب وایي چې DOMAIN\ لرې کړئ. بل وایي چې دا اضافه کړئ. دواړه بدلونونه ستاسو د پراکسي لپاره غلط کېدای شي.
دوه پوښتنې شته: خدمت کوم هویت ته انتظار لري، او ټاکل شوی API هغه هویت څنګه استازیتوب کوي.
| مخ | څه باید وټاکل شي |
|---|---|
| یوه حساب-نوم ساحه | هغه دقیق حساب جمله چې آپریټر یې مني |
| د ډومېن ساحې سره د اسنادو API | ایا ډومېن او کارن نوم باید جلا ورکړل شي |
| په URI کې د اسنادو برخې | په نظر کې نیول شوي ارزښتونه باید د هغې لوښي لپاره څنګه کوډ شي |
د بېلګې په توګه، .NET د کارن نوم، پټ نوم او ډومېن لپاره جلا استدلالونو سره NetworkCredential جوړوونکی وړاندې کوي. د ډومېن په دوو ساحو کې پرته له توپیر ځای پرځای کول د یوځای شوې تصدیق کولو د تنظیم وړ لاره نه ده.
Basic تصدیق بل حالت دی: سرور د ورکړل شوي حساب متن د خپلې پالیسۍ له مخې تفسیروي. په یوه شبکه کې اوسېدل نه ثابتوي چې د ډومېن مخکښه ضمناً موجوده ده. همدارنګه د ډومېن سره سمون لرونکی نوم په خپله بل د تصدیق پروتوکول نه دی.
د URL تېښته باید په نظر کې نیول شوی حساب وساتي نه دا چې بدل یې کړي. په سرچینې ژبې تار کې شاته مایل کرښه، په حساب نوم کې شاته مایل کرښه او په URI کې د هغې سلنه کوډ شوې بڼه جلا طبقې دي.
له آپریټر څخه منل شوې د هویت بڼه او سکیم ترلاسه کړئ، بیا مربوط د اسنادو مخ وکاروئ. د لنډ نوم، ډومېن نوم او برېښنالیک ته ورته نوم ترمنځ ناڅاپي بدلون د اصلي 407 په اړه کمزوري شواهد جوړوي.