ප්‍රොක්සි අක්‍රමාංකවල ඩොමේන්-සුදුසු පරිශීලක නාම
අපැහැදිලි ගිණුම් නාමය වෙන වෙනම ඩොමේන් ක්ෂේත්‍ර සහිත API වලින් වෙන් කරන්න, සහ URL වාක්‍ය ව්‍යුහය සපුරාලීමට පමණක් ගිණුම් අනන්‍යතාවය වෙනස් කිරීමෙන් වළකින්න.
එක් පිළිතුරක් කියන්නේ DOMAIN\ ඉවත් කරන්න කියාය. තවත් එකක් කියන්නේ එය එකතු කරන්න කියාය. දෙකම ඔබේ ප්‍රොක්සියට වැරදි විය හැක.
ප්‍රශ්න දෙකක් ඇත: සේවාව බලාපොරොත්තු වන්නේ කුමන අනන්‍යතාවයද, සහ තෝරාගත් API එම අනන්‍යතාවය නියෝජනය කරන්නේ කෙසේද.
| අතුරු මුහුණත | තහවුරු කළ යුත්තේ කුමක්ද |
|---|---|
| තනි ගිණුම්-නාම ක්ෂේත්‍රයක් | ක්‍රියාකරු පිළිගන්නා නිශ්චිත ගිණුම් වාක්‍ය ව්‍යුහය |
| ඩොමේන් ක්ෂේත්‍රයක් සහිත අක්‍රමාංක API | ඩොමේන් සහ පරිශීලක නාමය වෙන වෙනම ලබා දිය යුතුද |
| URI තුළ ඇති අක්‍රමාංක සංරචක | අදහස් කළ අගයන් එම බහාලුමට කෙසේ සංකේතනය කළ යුතුද |
උදාහරණයක් ලෙස, .NET වෙන වෙනම පරිශීලක නාම, මුරපදය සහ ඩොමේන් තර්ක සහිත NetworkCredential නිර්මාණකයක් ලබා දෙයි. ඩොමේන් භේදයකින් තොරව ක්ෂේත්‍ර දෙකක තැබීම ඒකාබද්ධ සත්‍යාපනය වින්‍යාස කිරීමේ ගෙනයා හැකි ක්‍රමයක් නොවේ.
Basic සත්‍යාපනය තවත් අවස්ථාවකි: සේවාදායකය ලබා දුන් ගිණුම් පෙළ තමන්ගේ ප්‍රතිපත්තිය යටතේ අර්ථ දක්වයි. එකම ජාලයේ සිටීම ඩොමේන් උපසර්ගය ව්‍යංගයෙන් ඇති බව ඔප්පු නොකරයි. ඩොමේන්-සුදුසු නාමයක් ස්වයංක්‍රීයව වෙනත් සත්‍යාපන ප්‍රොටෝකෝලයක් ද නොවේ.
URL උපක්‍රමය අදහස් කළ ගිණුම රැක ගත යුතුය, එය වෙනස් නොකළ යුතුය. මූල භාෂාවේ තන්තුවේ ඇති පසුකොකුව, ගිණුම් නාමයේ ඇති පසුකොකුව සහ URI තුළ එහි ප්‍රතිශත-සංකේතිත නිරූපණය වෙන වෙනම ස්තර වේ.
ක්‍රියාකරුගෙන් පිළිගත් අනන්‍යතා ස්වරූපය සහ යෝජනා ක්‍රමය ලබා ගෙන, පසුව අදාළ අක්‍රමාංක අතුරු මුහුණත භාවිත කරන්න. කෙටි නාමයක්, ඩොමේන් නාමයක් සහ විද්‍යුත් තැපෑලක් වැනි නාමයක් අතර අහඹු ලෙස මාරු වීම මුල් 407 පිළිබඳ දුර්වල සාක්ෂි ඇති කරයි.