HTTP 407 କି 401: କେଉଁ ଲଗଇନ୍ ବିଫଳ ହେଉଛି?

ପ୍ରକ୍ସି ଓ ୱେବସାଇଟ୍‌ର ପ୍ରାମାଣୀକରଣ ଅଲଗା କରନ୍ତୁ, ଠିକ୍ ହେଡର୍ ଦେଖନ୍ତୁ ଏବଂ ଭୁଲ୍ ପକ୍ଷକୁ ଲଗଇନ୍ ତଥ୍ୟ ପଠାନ୍ତୁ ନାହିଁ।

407 ପ୍ରକ୍ସିରେ ପ୍ରାମାଣୀକରଣ ମାଗେ। 401 ଲକ୍ଷ୍ୟ ସମ୍ବଳ ପାଇଁ ପ୍ରାମାଣୀକରଣ ମାଗେ। ଗୋଟିଏ ଅନୁରୋଧ ଉଭୟକୁ ଭେଟିପାରେ; ପାସୱାର୍ଡ ଦେବା ପୂର୍ବରୁ କିଏ ମାଗୁଛି ଜାଣନ୍ତୁ।

ଷ୍ଟାଟସ୍ ଓ ପ୍ରାମାଣୀକରଣ ଚ୍ୟାଲେଞ୍ଜ୍ ହେଡର୍ ତୁଳନା କରନ୍ତୁ

ପ୍ରତିକ୍ରିୟାଚ୍ୟାଲେଞ୍ଜ୍ ହେଡର୍ଲଗଇନ୍ ତଥ୍ୟର ହେଡର୍ସମ୍ପୃକ୍ତ ପକ୍ଷ
407 Proxy Authentication RequiredProxy-AuthenticateProxy-Authorizationମଧ୍ୟସ୍ଥ ପ୍ରକ୍ସି
401 UnauthorizedWWW-AuthenticateAuthorizationମୂଳ ସମ୍ବଳର ପ୍ରାମାଣୀକରଣ ପ୍ରବାହ

ଷ୍ଟାଟସ୍ ପ୍ରଥମ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ସୂତ୍ର, କିନ୍ତୁ ସମ୍ପୂର୍ଣ୍ଣ ଆଦାନପ୍ରଦାନ ଦେଖନ୍ତୁ। ପୃଷ୍ଠାର ଲେଖାରେ 407 ଥିବା ପ୍ରକୃତ HTTP 407 ପ୍ରତିକ୍ରିୟା ନୁହେଁ। ସେହିପରି ନିଜସ୍ୱ ଲଗଇନ୍ ପୃଷ୍ଠା 200 ଫେରାଇ ମଧ୍ୟ ଆପ୍ଲିକେସନ୍ ସ୍ତରରେ ପ୍ରାମାଣୀକରଣ ମାଗିପାରେ।

HTTPS ୱେବସାଇଟ୍‌ରେ ପହଞ୍ଚିବା ଆଗରୁ 407 ରେ କାହିଁକି ବିଫଳ ହୋଇପାରେ?

ସାଧାରଣ HTTP ପ୍ରକ୍ସି HTTPS ଅନୁରୋଧ ବହନ କଲେ କ୍ଲାଏଣ୍ଟ ସାଧାରଣତଃ ଆଗେ CONNECT ଟନେଲ୍ ମାଗେ। ପ୍ରକ୍ସି ସେହି CONNECT ଅନୁରୋଧର ପ୍ରାମାଣୀକରଣ ମାଗିପାରେ। ଏହା ସରିନଥିଲେ ଟନେଲ୍ ଦେଇ ଗନ୍ତବ୍ୟର TLS ସେସନ୍ ଏପର୍ଯ୍ୟନ୍ତ ତିଆରି ହୋଇନାହିଁ। ୱେବସାଇଟ୍‌ର API ଟୋକନ୍ ବଦଳାଇ ଏହି ପର୍ଯ୍ୟାୟ ଠିକ୍ ହେବାର ସମ୍ଭାବନା କମ୍।

ବିସ୍ତୃତ ଆଉଟପୁଟ୍‌ରେ ଚ୍ୟାଲେଞ୍ଜ୍ କେଉଁଠି ଆସୁଛି ଦେଖନ୍ତୁ:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

ସ୍ଥାନୀୟ ଲିସେନର୍ ବଦଳରେ ନିଜର ଦେଇ ଲଗ୍‌ର ପ୍ରଥମ ଚ୍ୟାଲେଞ୍ଜ୍ ପଢ଼ନ୍ତୁ। CONNECT ବେଳେ 407 ଗନ୍ତବ୍ୟ TLS ପୂର୍ବରୁ ଆସେ; ସଫଳ ଟନେଲ୍ ପରେ 401 ଆସିପାରେ।

ପ୍ରକ୍ସି ତଥ୍ୟ ତାହାର ଇଣ୍ଟରଫେସ୍ ଦେଇ ପ୍ରଦାନ କରନ୍ତୁ

ବିଶ୍ୱସନୀୟ ପ୍ରଶାସକ ଦେଇଥିବା ଏଣ୍ଡପଏଣ୍ଟ ଓ ଖାତା ପାଇଁ curl ପ୍ରାମାଣୀକରଣ ପଦ୍ଧତି ସ୍ଥିର କରି ଦିଆଯାଇନଥିବା ପାସୱାର୍ଡ ପଚାରିପାରେ:

curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/

ଉଦାହରଣର ଏଣ୍ଡପଏଣ୍ଟ ଓ ବ୍ୟବହାରକାରୀକୁ ଅନୁମୋଦିତ ସେବାର ତଥ୍ୟରେ ବଦଳାନ୍ତୁ। କେବଳ ବ୍ୟବହାରକାରୀ ଦେଲେ ଉପର କମାଣ୍ଡରେ ସିଧା ପାସୱାର୍ଡ ରଖିବାକୁ ହୁଏ ନାହିଁ। ସମର୍ଥିତ ପଦ୍ଧତି curl ବିଲ୍ଡ ଓ ପ୍ରକ୍ସି ଅନୁସାରେ ବଦଳେ; ବୁଝାମଣା ବିଫଳ ହେଲେ ପ୍ରକୃତ ଚ୍ୟାଲେଞ୍ଜ୍ ଓ ବିଲ୍ଡର କ୍ଷମତା ଦେଖନ୍ତୁ।

ପ୍ରକ୍ସି ପ୍ରାମାଣୀକରଣ ବିକଳ୍ପ curl ର ମୂଳ ସର୍ଭର ବ୍ୟବହାରକାରୀ ପ୍ରାମାଣୀକରଣରୁ ଅଲଗା। ପ୍ରକ୍ସି ଚ୍ୟାଲେଞ୍ଜ୍‌ର ଉତ୍ତର ବଦଳରେ ମୂଳ ସର୍ଭରର Authorization ହେଡର୍ ଯୋଡ଼ନ୍ତୁ ନାହିଁ। ପ୍ରକ୍ସି ଲଗଇନ୍ ହେଡର୍ ହାତରେ ଅସମ୍ବନ୍ଧିତ ଅନୁରୋଧକୁ ପଠାନ୍ତୁ ନାହିଁ କିମ୍ବା ସମଗ୍ର ଆପ୍‌ରେ ପୁଣି ବ୍ୟବହାର ହେଉଥିବା ହେଡର୍‌ରେ ରଖନ୍ତୁ ନାହିଁ।

ପ୍ରକ୍ସି ବାରମ୍ବାର 407 ଫେରାଇଲେ

  • ଠିକ୍ ପ୍ରକ୍ସି ହୋଷ୍ଟ ଓ ପୋର୍ଟ ବ୍ୟବହାର ହେଉଥିବା ନିଶ୍ଚିତ କରନ୍ତୁ।
  • Basic ଭାବି ନେବା ବଦଳରେ ପ୍ରକ୍ସିର ଘୋଷିତ ପଦ୍ଧତି ଦେଖନ୍ତୁ।
  • ଖାତାର ଅବସ୍ଥା ଓ ସେବା ମାଗୁଥିବା ବ୍ୟବହାରକାରୀ ନାମର ରୂପ ନିଶ୍ଚିତ କରନ୍ତୁ।
  • ତଥ୍ୟ URL ରେ ଥିଲେ ବିଶେଷ ଅକ୍ଷର କିପରି ପଠାଯାଉଛି ଦେଖନ୍ତୁ।
  • ବ୍ରାଉଜର ସହ ଏକୀକୃତ ପ୍ରତିଷ୍ଠାନର ପ୍ରାମାଣୀକରଣକୁ ରନଟାଇମ୍ କିମ୍ବା ପ୍ଲାଟଫର୍ମ ସମର୍ଥନ ଲାଗେ କି ନାହିଁ ଜାଣନ୍ତୁ।
  • କ୍ଲାଏଣ୍ଟର ପ୍ରମାଣ ଯଥେଷ୍ଟ ନହେଲେ ପ୍ରଶାସକଙ୍କୁ ସମ୍ବେଦନଶୀଳ ତଥ୍ୟ ହଟାଯାଇଥିବା ଅନୁରୋଧ ପରିଚୟ କିମ୍ବା ସର୍ଭର ଲଗ୍ ଏଣ୍ଟ୍ରି ମାଗନ୍ତୁ।

ସଫଳ ଲଗଇନ୍ ପରେ ମଧ୍ୟ 403 କିମ୍ବା ନାକଚ CONNECT ପ୍ରବେଶ ନୀତିର ନିଷ୍ପତ୍ତି ହୋଇପାରେ। ଅଧିକ ପାସୱାର୍ଡ ଚେଷ୍ଟା ନିଷିଦ୍ଧ ଗନ୍ତବ୍ୟର ଅଧିକାର ଦିଏ ନାହିଁ।

ଗନ୍ତବ୍ୟର HTTPS ପ୍ରକ୍ସି ତଥ୍ୟର ପ୍ରତ୍ୟେକ ଆଦାନପ୍ରଦାନ ସୁରକ୍ଷିତ କରେ ନାହିଁ

ପ୍ରକ୍ସି ପ୍ରାମାଣୀକରଣ ଗନ୍ତବ୍ୟ TLS ପୂର୍ବରୁ ହୋଇପାରେ। ପ୍ରକ୍ସି ପର୍ଯ୍ୟନ୍ତ ସଂଯୋଗ ଏନ୍‌କ୍ରିପ୍ଟ ନଥିଲେ ଓ ପଦ୍ଧତି ତାହାରେ ପୁନଃବ୍ୟବହାରଯୋଗ୍ୟ ତଥ୍ୟ ଖୋଲିଦେଲେ HTTPS ଗନ୍ତବ୍ୟ ପୂର୍ବର ଆଦାନପ୍ରଦାନକୁ ପରେ ସୁରକ୍ଷା ଦିଏ ନାହିଁ। ସେବା ପାଇଁ ଉପଯୁକ୍ତ ଟ୍ରାନ୍ସପୋର୍ଟ ଓ ପ୍ରାମାଣୀକରଣ ବାଛନ୍ତୁ; ଅଜଣା ସାର୍ବଜନୀନ ପ୍ରକ୍ସିକୁ ବ୍ୟକ୍ତିଗତ ଖାତା ପଠାନ୍ତୁ ନାହିଁ।

ବିସ୍ତୃତ ଲଗ୍ ବାଣ୍ଟିବା ପୂର୍ବରୁ ଦେଖନ୍ତୁ। ସାଧାରଣ ଲଗଇନ୍ କ୍ଷେତ୍ର ଲୁଚାଇଲେ ମଧ୍ୟ ବ୍ୟବହାରକାରୀ ନାମ, ଆଭ୍ୟନ୍ତରୀଣ ଏଣ୍ଡପଏଣ୍ଟ ନାମ, କୁକି କିମ୍ବା ଅନ୍ୟ ପରିଚୟ ତଥ୍ୟ ରହିପାରେ।

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