په curl کې د NTLM پراکسي ننوتلو تشخیص

د 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 پټنوم ثبوت.

تفصیلي نښې د هویت تصدیق ټوکنونه او داخلي نومونه لرلای شي. په ځايي ډول یې وکاروئ او تر شریکولو مخکې حساس معلومات لېرې کړئ؛ د عامې تېروتنې راپور خام ټوکن تبادلې ته اړتیا نه لري.