Squid चे Basic प्रमाणीकरण जुना पासवर्ड अजून का स्वीकारते

Squid ची पासवर्ड फाइल बदलल्याने पुढील प्रत्येक विनंतीने मदतनीस प्रोग्रामला पुन्हा बोलावलेच पाहिजे असे नाही. Basic प्रमाणीकरणात Squid यशस्वीरीत्या तपासलेली वापरकर्ता-नाव आणि पासवर्डाची जोडी कॅश करू शकते.

ही तपासणी किती काळ वैध मानायची हे नियंत्रित करणारी Squid 6.13 सेटिंग credentialsttl आहे. उदाहरणार्थ:

auth_param basic credentialsttl 5 minutes

हे धोरण-मूल्याचे उदाहरण आहे, सार्वत्रिक शिफारस नाही. स्वीकारता येणारा प्रवेश-रद्द विलंब आणि तुमचे प्रमाणीकरण बॅकएंड सहन करू शकेल इतका भार यानुसार निवडा.

तीन तपासण्या वेगळ्या ठेवा

प्रथम सक्रिय मदतनीस वापरत असलेली फाइल संपादित केली आहे याची खात्री करा. न वापरलेल्या फाइलमधील योग्य बदलाचा परिणाम होत नाही. नंतर मदतनीस फाइल वाचून नवीन खाते माहिती तपासू शकतो का ते पाहा. शेवटी चालू इन्स्टन्समधून नवीन प्रॉक्सी विनंती तपासा; तेथे क्रेडेन्शियल कॅश आणि प्रवेश नियमही लागू होतात.

मदतनीस आणि चालू प्रॉक्सी स्वतंत्रपणे तपासा. बॅकएंड सध्या काय स्वीकारतो ते मदतनीस दाखवतो, पण Squid कॅश केलेली तपासणी पुन्हा वापरू शकतो. क्रेडेन्शियल बदलताना नवीन माहिती चालते आणि लागू तपासणी कालावधीनंतर जुनी नाकारली जाते हे दोन्ही तपासा.

हे वर्तन तपासण्यासाठी स्वतंत्र चाचणी खाते वापरा. विनंती, क्लायंटचा स्रोत आणि लक्ष्य समान ठेवा आणि सामायिक कमांड आउटपुटमध्ये खरे पासवर्ड देऊ नका.

फाइल बदलावर अवलंबून न राहता रद्द करण्याचे नियोजन करा

तपासणीची कमी वैधता बॅकएंडचे काम वाढवते. व्यस्त सेवेत ती कमी करण्यापूर्वी मदतनीसांची क्षमता विचारात घ्या आणि प्रत्यक्ष बॅकएंडवर वर्तन तपासा. तुमच्या आवृत्ती आणि मांडणीसाठी सिद्ध नसल्यास कॉन्फिगरेशन पुन्हा लोड केल्याने प्रमाणीकरणाची सर्व संबंधित स्थिती साफ होते असे समजू नका.

तातडीने प्रवेश काढण्यासाठी खाते किंवा स्रोतावर स्पष्ट प्रवेशबंदी वेगळी सीमा देऊ शकते. पासवर्ड फाइलमधून काढण्यावरच विसंबू नका; बाधित मार्गावरून ती बंदी तपासा.

ही सेटिंग Basic तपासणीचे कॅशिंग वर्णन करते. जोडणी-केंद्रित प्रमाणीकरण योजनांना अतिरिक्त स्थिती असते आणि केवळ साधर्म्यामुळे त्यांना तेच रद्दीकरण मॉडेल देऊ नये.