ଆପଣଙ୍କ 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 ପରି ବିବରଣୀ ଆଗକୁ ପଠାଇବା ବିକଳ୍ପ ମଧ୍ୟ ଅଛି। ସେଗୁଡ଼ିକର ଅର୍ଥ ନିର୍ଦ୍ଦିଷ୍ଟ ଅପଷ୍ଟ୍ରିମ ଖାତାଠାରୁ ଅଲଗା ଏବଂ କ୍ଲାଏଣ୍ଟର ପ୍ରମାଣୀକରଣ ତଥ୍ୟ peerକୁ ଦେଖାଇପାରେ। ଡିଜାଇନ ଅଲଗା ଖାତା ବ୍ୟବହାର କଲେ ସହଜ ରାସ୍ତା ଭାବେ ସେଗୁଡ଼ିକୁ ବାଛନ୍ତୁ ନାହିଁ।

ବିନ୍ୟାସ ସୁରକ୍ଷିତ କରନ୍ତୁ ଏବଂ ଠିକ ହପ ପରୀକ୍ଷା କରନ୍ତୁ

ସ୍ଥିର ଗୋପନ ତଥ୍ୟ ବିନ୍ୟାସରେ ରହେ। ଫାଇଲ ଓ ବ୍ୟାକଅପ ପ୍ରବେଶ ସୀମିତ କରି parser କିମ୍ବା debug ଆଉଟପୁଟ ବାଣ୍ଟିବା ପୂର୍ବରୁ ସମ୍ବେଦନଶୀଳ ତଥ୍ୟ ହଟାନ୍ତୁ। ବିକଳ୍ପର ନିଜ escaping ନିୟମ ଅଛି: ଦଲିଲ URL escapes ଅନୁମତି ଦିଏ ଏବଂ ସିଧା ପ୍ରତିଶତ ଚିହ୍ନ ଦୁଇଥର ଲେଖିବାକୁ କହେ।

କ୍ଲାଏଣ୍ଟ ପ୍ରମାଣୀକରଣ ସଫଳ ହେଲେ ବି ପଠାଯାଇଥିବା ଅନୁରୋଧ ପେରେଣ୍ଟରେ ବିଫଳ ହେଲେ ସେହି ଅପଷ୍ଟ୍ରିମ ଆଦାନପ୍ରଦାନ ଏବଂ ଖାତା ଯାଞ୍ଚ କରନ୍ତୁ। କ୍ଲାଏଣ୍ଟ–Squid ଏବଂ Squid–ପେରେଣ୍ଟ ପରିବହନ ସୁରକ୍ଷା ମଧ୍ୟ ଅଲଗା ରଖନ୍ତୁ; ପ୍ରଥମ ସଂଯୋଗ ଏନକ୍ରିପ୍ଟ କଲେ ଦ୍ୱିତୀୟଟି ଆପେଆପେ ସୁରକ୍ଷିତ ହୁଏ ନାହିଁ।

ସମ୍ପର୍କିତ ପ୍ରବନ୍ଧ