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 પાસવર્ડનો પુરાવો નથી.

વિગતવાર ટ્રેસમાં પ્રમાણીકરણ ટોકન અને આંતરિક નામો હોઈ શકે. સ્થાનિક રીતે વાપરો અને શેર કરતાં પહેલાં સંવેદનશીલ માહિતી દૂર કરો; જાહેર ભૂલ અહેવાલમાં કાચી ટોકન આપલે જરૂરી નથી.

સંબંધિત લેખો