NTLM ప్రాక్సీ ప్రామాణీకరణలో హ్యాండ్‌షేక్ ఉంటుంది; వినియోగదారు పేరును ఒక్కసారి జోడించడం మాత్రమే కాదు. ఖాతా పాస్‌వర్డ్ మార్చేముందు ప్రాక్సీ నిజంగా NTLM అందిస్తుందని మరియు curl ఎగ్జిక్యూటబుల్ దానికి మద్దతిస్తుందని నిర్ధారించండి.

curl --version

మీ అభ్యర్థనను నడిపే ఎగ్జిక్యూటబుల్ ఫీచర్ల జాబితా పరిశీలించండి. వేరే curl ఇన్‌స్టాలేషన్, కంటైనర్ ఇమేజ్ లేదా ఆపరేటింగ్ సిస్టమ్ బిల్డ్‌లో ప్రామాణీకరణ మద్దతు వేరుగా ఉండవచ్చు.

ప్రాక్సీకి ప్రత్యేకమైన పద్ధతిని ఎంచుకోండి

curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/

ఎండ్‌పాయింట్, డొమైన్, వినియోగదారు పేరు ఉదాహరణలు. నిర్వాహకుడు ఇచ్చిన ఫార్మాట్ వాడండి. ఆర్గ్యుమెంట్‌లో పాస్‌వర్డ్ లేకపోతే కనిపించే కమాండ్‌లో రహస్యాన్ని మిగల్చకుండా curl దాన్ని అడగవచ్చు.

మొదటి ప్రామాణీకరణ సవాలు చర్చలో భాగం కావచ్చు. దాన్ని పూర్తయిన హ్యాండ్‌షేక్ తర్వాత తిరస్కరణ నుంచి వేరు చేయండి. ప్రాక్సీ సవాలుకు సమాధానంగా మూల సర్వర్ NTLM ఆప్షన్ ఉపయోగించవద్దు.

నిర్ధారణలో కనెక్షన్ ప్రవర్తనను కూడా చేర్చండి

NTLM స్థితి కనెక్షన్‌కు పరిమితమై ఉంటుంది. హ్యాండ్‌షేక్ ఆశించిన కనెక్షన్ మార్గంలో జరగాలి; దశల మధ్య కనెక్షన్‌లను పదేపదే మార్చడం పూర్తి కావడాన్ని అడ్డుకోవచ్చు.

Libcurl ఉపయోగించే అప్లికేషన్‌లో ప్రామాణీకరణ, కనెక్షన్ పునర్వినియోగాన్ని లైబ్రరీ నిర్వహించనివ్వండి. వేర్వేరు గుర్తింపుల కోసం ప్రామాణీకరించిన కనెక్షన్‌లను పరస్పరం మార్చుకోగలవిగా భావించే సాధారణ పూల్ రూపొందించవద్దు. పలు హాప్‌లు లేదా మధ్యవర్తి సేవ ఉంటే అవసరమైన కనెక్షన్ ఏర్పాటును అది కాపాడుతుందో చూడండి.

మద్దతు, పద్ధతి ఎంపిక సరైనవైతే ఖాతా ఫార్మాట్, డొమైన్ పాలసీ, సున్నితమైన డేటా తొలగించిన సర్వర్ ప్రామాణీకరణ లాగ్‌లను పరిశీలించండి. ఏ సవాలుకైనా ముందే సమయం ముగియడం ఇంకా చేరుకోగలగడపు సమస్యే; తప్పు NTLM పాస్‌వర్డ్‌కు ఆధారం కాదు.

వివరమైన ట్రేస్‌లలో ప్రామాణీకరణ టోకెన్‌లు, అంతర్గత పేర్లు ఉండవచ్చు. వాటిని స్థానికంగా వాడి పంచుకునే ముందు సున్నితమైన డేటా తొలగించండి; బహిరంగ దోష నివేదికకు ముడి టోకెన్ మార్పిడి అవసరం లేదు.

సంబంధిత వ్యాసాలు