Majina ya watumiaji yenye kikoa katika vitambulisho vya proksi
Tofautisha jina la akaunti lisilo wazi na API zenye sehemu za kikoa tofauti, na epuka kubadilisha utambulisho wa akaunti ili tu kukidhi sintaksia ya URL.
Jibu moja linasema uondoe DOMAIN\. Jengine linasema uiongeze. Mabadiliko yote mawili yanaweza kuwa makosa kwa proksi yako.
Kuna maswali mawili: ni utambulisho gani huduma inatarajia, na API iliyochaguliwa inawakilishaje utambulisho huo.
| Kiolesura | Nini cha kuthibitisha |
|---|---|
| Sehemu moja ya jina la akaunti | Sintaksia kamili ya akaunti ambayo mwendeshaji hukubali |
| API ya vitambulisho yenye sehemu ya kikoa | Ikiwa kikoa na jina la mtumiaji vinapaswa kutolewa tofauti |
| Vipengele vya vitambulisho ndani ya URI | Jinsi thamani zinazokusudiwa zinapaswa kusimbwa kwa chombo hicho |
Kwa mfano, .NET hutoa kijenzi NetworkCredential chenye hoja tofauti za jina la mtumiaji, nenosiri na kikoa. Kuweka kikoa katika sehemu mbili bila ubaguzi si njia inayoweza kuhamishwa ya kusanidi uthibitishaji jumuishi.
Uthibitishaji wa Basic ni kisa kingine: seva hutafsiri maandishi ya akaunti yaliyotolewa kwa mujibu wa sera yake. Kuwa kwenye mtandao mmoja hakuthibitishi kwamba kiambishi cha kikoa kinadokezwa. Wala jina lenye kikoa haliwi kiotomatiki itifaki nyingine ya uthibitishaji.
Uepushaji wa URL unapaswa kuhifadhi akaunti inayokusudiwa badala ya kuibadilisha. Mstari wa nyuma katika mfuatano wa lugha chanzi, mstari wa nyuma katika jina la akaunti na uwakilishi wake uliosimbwa kwa asilimia ndani ya URI ni tabaka tofauti.
Pata umbo la utambulisho na mpango unaokubalika kutoka kwa mwendeshaji, kisha tumia kiolesura cha vitambulisho kinacholingana. Kubadilisha bila mpangilio kati ya jina fupi, jina la kikoa na jina linalofanana na barua pepe huzalisha ushahidi hafifu kuhusu 407 ya awali.