د Squid د پورته پراکسي لپاره جلا د ننوتلو معلومات وټاکئ

ستاسو Squid خدمت ته د کارن ننوتل او د Squid خپل پورته پراکسي ته ننوتل جلا معلومات کاروي. پورته پراکسي ښايي د بل چلوونکي وي یا بله د حسابونو زېرمه وکاروي. د مراجع پټنوم منل دا نه مانا کوي چې باید پورته یې واستوئ.

Squid 6.13 د پورته پراکسي تعریف ته ثابت د ننوتلو معلومات ورزیاتولای شي:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly

پورته پته او پټنوم د سند بېلګې دي. ننوتل موجود پورته پراکسي تعریف ته ورزیات کړئ، نه دا چې په تېروتنه دویم peer جوړ کړئ. هغه جلا د لارې تګلاره وساتئ چې ټاکي کومې غوښتنې باید دا پورته پراکسي وکاروي.

د حسابونو ساحې بېلې وساتئ

د لاندې لوري auth_param تنظیمونه ستاسو د Squid نسخې مراجعین تاییدوي. د peer د login غوراوی د بل ګام لپاره معلومات ورکوي. د یوه بدلول بل په اوتومات ډول نه تازه کوي.

د پورته پراکسي مستند د هویت تصدیق اړتیاوې پوره کړئ. دا کرښه د هرې پیوستون‌محورې تصدیق طریقې بشپړ تنظیم نه دی. که پورته پراکسي NTLM یا Negotiate غواړي، په دې ډګر کې د پټنوم تکراري بدلولو پر ځای د ملاتړ وړ peer جوړښت وګورئ.

Squid د PASS او PASSTHRU په څېر د ننوتلو معلوماتو د لېږدولو غوراوي هم لري. مانا یې له ځانګړي upstream حساب سره توپیر لري او د مراجع د تصدیق معلومات peer ته ښکاره کولای شي. که طرحه جلا حسابونه غواړي، د لنډې لارې په توګه یې مه ټاکئ.

تنظیم خوندي کړئ او سم ګام وازمویئ

ثابت راز په تنظیم کې ساتل کېږي. فایلونو او بیک‌اپونو ته لاسرسی محدود کړئ او د parser یا debug پایلې له شریکولو مخکې له حساسو معلوماتو پاکې کړئ. دا غوراوی خپل escaping اصول لري: سند د URL escapes اجازه ورکوي او وايي چې اصلي سلنې نښه باید دوه ځله ولیکل شي.

که مراجعین په بریالیتوب تصدیق شي، خو لېږل شوې غوښتنې لا هم په پورته پراکسي کې ناکامېږي، هغه upstream تبادله او حساب وګورئ. د مراجع–Squid او Squid–پورته پراکسي د لېږد ساتنه هم بېله کړئ؛ د لومړي پیوستون کوډول دویم په اوتومات ډول نه خوندي کوي.