Squidની પાસવર્ડ ફાઇલ બદલવાથી દરેક પછીની વિનંતી સહાયક પ્રોગ્રામને ફરી બોલાવશે જ એવું નથી. Basic પ્રમાણીકરણમાં Squid સફળતાથી ચકાસેલી વપરાશકર્તાનામ અને પાસવર્ડની જોડીને કેશમાં રાખી શકે છે.

આ ચકાસણી કેટલો સમય માન્ય ગણાય તે નિયંત્રિત કરતું Squid 6.13નું સેટિંગ credentialsttl છે. ઉદાહરણ તરીકે:

auth_param basic credentialsttl 5 minutes

આ નીતિમૂલ્યનું ઉદાહરણ છે, સર્વત્ર લાગુ ભલામણ નથી. સ્વીકાર્ય પ્રવેશ રદ કરવાનો વિલંબ અને તમારું પ્રમાણીકરણ બેકએન્ડ સંભાળી શકે તે ભાર પ્રમાણે તેને પસંદ કરો.

ત્રણ તપાસો અલગ કરો

પહેલાં ખાતરી કરો કે તમે સક્રિય સહાયક પ્રોગ્રામ વાપરે છે તે ફાઇલ સંપાદિત કરી છે. ન વપરાતી ફાઇલમાં સાચા ફેરફારની પણ અસર નથી. પછી સહાયક ફાઇલ વાંચી શકે અને નવી ખાતાની માહિતી ચકાસી શકે તે જુઓ. છેલ્લે ચાલતા ઇન્સ્ટન્સ મારફતે નવી પ્રોક્સી વિનંતી અજમાવો, જ્યાં ઓળખપત્રોની કેશ અને પ્રવેશના નિયમો પણ લાગુ પડે છે.

સહાયક પ્રોગ્રામ અને ચાલતી પ્રોક્સી અલગથી ચકાસો. સહાયક હાલ બેકએન્ડ શું સ્વીકારે છે તે બતાવે છે, જ્યારે Squid હજી કેશની ચકાસણી ફરી વાપરી શકે છે. ઓળખપત્રો બદલતી વખતે નવાં કામ કરે છે અને સંબંધિત ચકાસણી સમયગાળા પછી જૂનાં નકારાય છે તે બંને તપાસો.

આ વર્તન તપાસવા માટે ખાસ પરીક્ષણ ખાતું વાપરો. વિનંતી, ક્લાયન્ટનો સ્રોત અને લક્ષ્ય સમાન રાખો અને શેર કરેલા આદેશના આઉટપુટમાં વાસ્તવિક પાસવર્ડ ન મૂકો.

ફાઇલ ફેરફાર પર આધાર રાખવાને બદલે પ્રવેશ રદ કરવાનું આયોજન કરો

ચકાસણીની ટૂંકી માન્યતા બેકએન્ડનું કામ વધારે છે. વ્યસ્ત સેવામાં તેને ઘટાડતાં પહેલાં સહાયકોની ક્ષમતા વિચારો અને વાસ્તવિક બેકએન્ડથી વર્તન ચકાસો. તમારા સંસ્કરણ અને ગોઠવણ માટે સાબિત ન હોય ત્યાં સુધી રૂપરેખા ફરી લોડ કરવાથી પ્રમાણીકરણની બધી સંબંધિત સ્થિતિ સાફ થાય છે એવું ન માનો.

તાત્કાલિક પ્રવેશ દૂર કરવા ખાતા કે સ્રોત માટે સ્પષ્ટ પ્રવેશ પ્રતિબંધ અલગ સીમા આપી શકે છે. ફક્ત પાસવર્ડ ફાઇલમાંથી કાઢવા પર આધાર રાખવાને બદલે અસરગ્રસ્ત માર્ગ પરથી તે પ્રતિબંધ ચકાસો.

આ સેટિંગ Basic ચકાસણીની કેશ વર્ણવે છે. જોડાણ આધારિત પ્રમાણીકરણ યોજનાઓમાં વધારાની સ્થિતિ હોય છે; માત્ર સરખામણીથી તેમને સમાન રદ કરવાનો મોડેલ ન આપવો જોઈએ.

સંબંધિત લેખો