HTTP 407 که 401: کوم ننوتل ناکامېږي؟
د پراکسي او وېبپاڼې هویت تایید سره جلا کړئ، سم سرلیکونه وګورئ او د ننوتلو معلومات ناسم اړخ ته مه لېږئ.
407 په پراکسي کې د هویت تایید غواړي. 401 یې د هدف سرچینې لپاره غواړي. یوه غوښتنه له دواړو سره مخ کېدای شي؛ د پټنوم تر ورکولو مخکې معلومه کړئ چې څوک یې غواړي.
حالت او د هویت تایید د ننګونې سرلیکونه پرتله کړئ
| ځواب | د ننګونې سرلیک | د ننوتلو معلوماتو سرلیک | اړوند لوری |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | منځګړې پراکسي |
| 401 Unauthorized | WWW-Authenticate | Authorization | د اصلي سرچینې د هویت تایید بهیر |
حالت لومړنۍ مهمه نښه ده، خو ټوله تبادله وګورئ. د پاڼې په متن کې 407 د ریښتیني HTTP 407 ځواب برابر نه دی. همدارنګه ځانګړې د ننوتلو پاڼه 200 راستنولای شي او بیا هم د کاریال په پوړ کې تایید وغواړي.
HTTPS ولې وېبپاڼې ته تر رسېدو مخکې په 407 ناکامېدای شي؟
عادي HTTP پراکسي چې HTTPS غوښتنه وړي، مراجع عموماً لومړی CONNECT تونل غواړي. پراکسي د همدې CONNECT غوښتنې لپاره تایید غوښتلای شي. که بشپړ نه شي، د مقصد TLS ناسته د تونل له لارې لا نه ده جوړه شوې. د وېبپاڼې API ټوکن بدلول ښايي دا پړاو سم نه کړي.
په مفصلې پایلې کې وګورئ چې ننګونه چېرته راځي:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/ځايي اورېدونکی په خپل بدل کړئ او د ثبت لومړنۍ ننګونه ولولئ. د CONNECT پر مهال 407 د مقصد TLS څخه مخکې وي؛ ورپسې 401 له بریالي تونل وروسته راتلای شي.
د پراکسي معلومات د هغې له انټرفېس ورکړئ
د باور وړ مدیر د ورکړي پای ټکي او حساب لپاره curl د پراکسي د تایید لاره ټاکلای او نه ورکړل شوی پټنوم پوښتلای شي:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/د بېلګې پای ټکی او کارن د مجاز خدمت په معلوماتو بدل کړئ. یوازې د کارن ټاکل پټنوم په پاسني امر کې مستقیم نه ږدي. ملاتړ شوې لارې د curl جوړښت او پراکسي سره توپیر کوي؛ خبرې اترې چې ناکامې شي، اصلي ننګونه او د جوړښت وړتیا وګورئ.
د پراکسي تایید اختیار د curl د اصلي سرور د کارن له تایید جلا دی. د پراکسي ننګونې د ځواب پر ځای د اصلي سرور Authorization سرلیک مه زیاتوی. د پراکسي د ننوتلو سرلیکونه هم په لاس نامربوطو غوښتنو ته مه لېږئ او د ټول کاریال په بیاکارېدونکو سرلیکونو کې یې مه ساتئ.
که پراکسي تل 407 راستنوي
- تایید کړئ چې ټاکلی پراکسي کوربه او پورټ کاروئ.
- د Basic پر اټکل د پراکسي اعلان شوې لارې وګورئ.
- د حساب حالت او د خدمت د کارن نوم ځانګړې بڼه تایید کړئ.
- معلومات چې په URL کې وي، د ځانګړو تورو لېږد وګورئ.
- معلومه کړئ چې له براوزر سره یوځای سازماني تایید د اجرا چاپېریال یا پلېټفارم ملاتړ ته اړتیا لري که نه.
- د مراجع شواهد چې بس نه وي، له مدیر څخه د حساسو معلوماتو پاکه شوې غوښتنې پېژندنه یا د سرور د ثبت توکی وغواړئ.
له بریالي ننوتلو وروسته هم 403 یا رد شوی CONNECT د لاسرسي تګلارې پرېکړه کېدای شي. نورې پټنوم هڅې منع شوي مقصد ته اجازه نه ورکوي.
د مقصد HTTPS د پراکسي د معلوماتو هره تبادله نه ساتي
د پراکسي تایید د مقصد TLS تر جوړېدو مخکې کېدای شي. که له پراکسي سره نښلونه ناکوډ شوې وي او لاره پرې بیاکارېدونکي معلومات ښکاره کړي، HTTPS مقصد پخوانۍ تبادله وروسته نه شي ساتلای. د خدمت مناسب لېږد او تایید وټاکئ؛ ناپېژندلې عامه پراکسي ته شخصي حسابونه مه لېږئ.
مفصل ثبتونه له شریکولو مخکې وګورئ. که وسیله عادي د ننوتلو خانې پټوي هم، د کارن نومونه، داخلي پای ټکي، کوکيز یا نور پېژندونکي معلومات پاتې کېدای شي.