Apache ଫରୱାର୍ଡ ପ୍ରକ୍ସି ଅନୁମତି: Require ଏବଂ AuthMerging
proxy.conf କୁ ପୃଥକ ନୀତି ସ୍ତର ଭାବରେ ଗ୍ରହଣ ନକରି Apache ର ବିଭାଗ-ମିଶ୍ରଣ ନିୟମ ମାଧ୍ୟମରେ ବୈଶ୍ୱିକ ଓ ଭର୍ଚୁଆଲ-ହୋଷ୍ଟ ପ୍ରକ୍ସି ଅନୁମତି ଅନୁସରଣ କରନ୍ତୁ।
proxy.conf ରେ ଥିବା ନିୟମ ଏକ ବିଶେଷ ନିୟମ ଶ୍ରେଣୀ ନୁହେଁ। Apache ସମାବେଶିତ କନଫିଗୁରେସନକୁ ନିଜର କନଫିଗୁରେସନ ଗଛରେ ପଢ଼େ; ଘେରିଥିବା ବୈଶ୍ୱିକ, VirtualHost କିମ୍ବା ମେଳ ଖାଉଥିବା ବିଭାଗ ନିର୍ଦ୍ଦେଶ କିପରି ଅଂଶଗ୍ରହଣ କରେ ତାହା ନିର୍ଣ୍ଣୟ କରେ।
ଫରୱାର୍ଡ-ପ୍ରକ୍ସି ଅନୁରୋଧକୁ ସେବା କରୁଥିବା ଲିଷ୍ଟନର ଓ ଭର୍ଚୁଆଲ ହୋଷ୍ଟରୁ ଆରମ୍ଭ କରନ୍ତୁ। ତା'ପରେ ସେହି ପ୍ରସଙ୍ଗ ଓ ମୁଖ୍ୟ କନଫିଗୁରେସନରୁ ମେଳ ଖାଉଥିବା Proxy ବିଭାଗଗୁଡ଼ିକ ସଂଗ୍ରହ କରନ୍ତୁ। ବିଭାଗଗୁଡ଼ିକର ପ୍ରକ୍ରିୟାକରଣ କ୍ରମ ମହତ୍ତ୍ୱପୂର୍ଣ୍ଣ, କେଉଁ ଫାଇଲ ଶେଷରେ ସମ୍ପାଦିତ ହେଲା ତାହା ମାତ୍ର ନୁହେଁ।
ଅନୁମତି ସର୍ବଦା ସଞ୍ଚୟୀ ନୁହେଁ
ଡିଫଲ୍ଟ AuthMerging Off ଆଚରଣ ସହିତ, ପରବର୍ତ୍ତୀ ପ୍ରଯୁଜ୍ୟ ବିଭାଗ ନିଜର ଅନୁମତି ତର୍କ ଯୋଗାଇବା ପର୍ଯ୍ୟନ୍ତ ଅନୁମତି ଉତ୍ତରାଧିକାର ସୂତ୍ରରେ ମିଳେ। ସେହି ନୂତନ ତର୍କ ଆଉ ଏକ ପ୍ରତିବନ୍ଧକ ଯୋଡ଼ିବା ପରିବର୍ତ୍ତେ ପୂର୍ବ ଆବଶ୍ୟକତାଗୁଡ଼ିକୁ ବଦଳାଇପାରେ।
| ସେଟିଂ | ନିକଟତମ ପୂର୍ବ ଅନୁମତି ବିଭାଗ ସହିତ ସଂଯୋଗ |
|---|---|
| Off | ନୂତନ ଅନୁମତି ଉତ୍ତରାଧିକାରୀ ତର୍କକୁ ଅତିକ୍ରମ କରିପାରେ |
| And | ଉଭୟ ସେଟ୍ ଅନୁମତି ଦେବା ଆବଶ୍ୟକ |
| Or | ଯେକୌଣସି ସେଟ୍ ଅନୁମତି ଦେଇପାରେ |
AuthMerging ନିଜେ ଏହାକୁ ଧାରଣ କରୁଥିବା ବିଭାଗ ପାଇଁ ସ୍ଥାନୀୟ। ଥରେ And ସେଟ୍ କଲେ ପ୍ରତ୍ୟେକ ପରବର୍ତ୍ତୀ ବିଭାଗ ବଦଳିଯିବ ବୋଲି ଭାବନ୍ତୁ ନାହିଁ।
ଯେତେ ସମ୍ଭବ ଉଦ୍ଦିଷ୍ଟ ନୀତିକୁ ସ୍ପଷ୍ଟ ରଖନ୍ତୁ। ଘେରିଥିବା ଅନୁମତି ଧାରକ ବିନା ଦୁଇଟି Require ଧାଡ଼ି ଅନ୍ତର୍ନିହିତ ଭାବରେ ବିକଳ୍ପ, ତେଣୁ IP ନିୟମ ସହିତ valid-user ସ୍ୱୟଂଚାଳିତ ଭାବରେ “IP ଏବଂ ବ୍ୟବହାରକାରୀ” ନୁହେଁ। ବ୍ୟବହାର କରନ୍ତୁ ଉଭୟ ସର୍ତ୍ତ ଏକ ନିଷ୍ପତ୍ତିର ହେଲେ RequireAll.
ପ୍ରକ୍ସି ଖାତା ବଦଳାଇବା କିମ୍ବା ପ୍ରବେଶ ଖୋଲିବା ପୂର୍ବରୁ ସମ୍ପୂର୍ଣ୍ଣ ମେଳ ଖାଉଥିବା କନଫିଗୁରେସନ ସମୀକ୍ଷା କରନ୍ତୁ। ତା'ପରେ ଚାଲୁଥିବା ଲିଷ୍ଟନର ବିରୁଦ୍ଧରେ ଅନୁମତିପ୍ରାପ୍ତ ଓ ଅସ୍ୱୀକୃତ କ୍ଷେତ୍ର ପରୀକ୍ଷା କରନ୍ତୁ। ଅନ୍ୟ ଏକ ବିଭାଗ ପ୍ରଭାବୀ ଅନୁମତି ଯୋଗାଇଥିବାରୁ ଅନୁରୋଧ ଅସ୍ୱୀକୃତ—କିମ୍ବା ଅପ୍ରତ୍ୟାଶିତ ଭାବରେ ଅନୁମତିପ୍ରାପ୍ତ—ହୋଇପାରେ।