ప్రాక్సీ ఆధారాలలో డొమైన్-అర్హత కలిగిన వినియోగదారు పేర్లు
అస్పష్టమైన ఖాతా పేరును వేర్వేరు డొమైన్ ఫీల్డ్‌లు ఉన్న APIల నుండి వేరు చేయండి, మరియు కేవలం URL వ్యాకరణాన్ని నెరవేర్చడానికి ఖాతా గుర్తింపును మార్చడం మానండి.
ఒక సమాధానం DOMAIN\ తీసివేయమని చెబుతుంది. మరొకటి దాన్ని జోడించమని చెబుతుంది. రెండు మార్పులు మీ ప్రాక్సీకి తప్పు కావచ్చు.
రెండు ప్రశ్నలు ఉన్నాయి: సేవ ఏ గుర్తింపును ఆశిస్తుంది, మరియు ఎంచుకున్న API ఆ గుర్తింపును ఎలా సూచిస్తుంది.
| ఇంటర్‌ఫేస్ | ఏమి నిర్ధారించాలి |
|---|---|
| ఒకే ఖాతా-పేరు ఫీల్డ్ | ఆపరేటర్ అంగీకరించే ఖచ్చితమైన ఖాతా వ్యాకరణం |
| డొమైన్ ఫీల్డ్ ఉన్న ఆధార API | డొమైన్ మరియు వినియోగదారు పేరు విడివిడిగా ఇవ్వాలా |
| URI లోపల ఆధార భాగాలు | ఉద్దేశించిన విలువలు ఆ కంటైనర్ కోసం ఎలా ఎన్‌కోడ్ చేయాలి |
ఉదాహరణకు, .NET వేర్వేరు వినియోగదారు పేరు, పాస్‌వర్డ్ మరియు డొమైన్ ఆర్గ్యుమెంట్‌లతో NetworkCredential కన్‌స్ట్రక్టర్‌ను అందిస్తుంది. డొమైన్‌ను భేదం లేకుండా రెండు ఫీల్డ్‌లలో పెట్టడం సమన్వయ ప్రామాణీకరణను కాన్ఫిగర్ చేసే పోర్టబుల్ మార్గం కాదు.
Basic ప్రామాణీకరణ మరో సందర్భం: సర్వర్ ఇచ్చిన ఖాతా పాఠ్యాన్ని తన సొంత విధానం ప్రకారం అర్థం చేసుకుంటుంది. ఒకే నెట్‌వర్క్‌లో ఉండటం డొమైన్ ఉపసర్గ అంతర్లీనంగా ఉందని నిరూపించదు. డొమైన్-అర్హత పేరు స్వయంచాలకంగా వేరే ప్రామాణీకరణ ప్రోటోకాల్ కూడా కాదు.
URL ఎస్కేపింగ్ ఉద్దేశించిన ఖాతాను కాపాడాలి, దాన్ని మార్చకూడదు. మూల భాషా స్ట్రింగ్‌లోని బ్యాక్‌స్లాష్, ఖాతా పేరులోని బ్యాక్‌స్లాష్ మరియు URI లోపల దాని శాతం-ఎన్‌కోడెడ్ రూపం వేర్వేరు పొరలు.
ఆపరేటర్ నుండి ఆమోదించబడిన గుర్తింపు రూపాన్ని మరియు స్కీమ్‌ను పొంది, ఆపై సంబంధిత ఆధార ఇంటర్‌ఫేస్‌ను ఉపయోగించండి. చిన్న పేరు, డొమైన్ పేరు మరియు ఈమెయిల్ లాంటి పేరు మధ్య యాదృచ్ఛికంగా మారడం అసలు 407 గురించి బలహీనమైన సాక్ష్యాన్ని సృష్టిస్తుంది.