ପ୍ରକ୍ସି ମାଧ୍ୟମରେ OmniAuth ଲଗଇନ୍ ଟ୍ରେସ୍ କରିବା

ଉପଭୋକ୍ତା “ସାଇନ୍ ଇନ୍” କ୍ଲିକ୍ କରନ୍ତି, ପ୍ରଦାତାଙ୍କ ପୃଷ୍ଠାରେ ପହଞ୍ଚନ୍ତି ଏବଂ Rails କୁ ଫେରନ୍ତି। ପରବର୍ତ୍ତୀ ପଦକ୍ଷେପ ତଥାପି ବିଫଳ ହୋଇପାରେ, କାରଣ ଏହା Rails ସର୍ଭରରୁ ନୂଆ ସଂଯୋଗ ଆରମ୍ଭ କରେ।

browser → provider authorization page → browser callback to Rails
Rails   → provider token endpoint → Rails

ବ୍ରାଉଜର ନିଜର ନେଟୱାର୍କ ବିନ୍ୟାସ ସହିତ ଅନୁମତି ରିଡାଇରେକ୍ଟ ଅନୁସରଣ କରେ। Rails ସ୍ଥାପିତ OmniAuth ରଣନୀତି ଦ୍ୱାରା ଚୟନିତ HTTP କ୍ଲାଏଣ୍ଟ ସହିତ ବ୍ୟାକଚ୍ୟାନେଲ୍ ଟୋକେନ୍ ବିନିମୟ କରେ। କର୍ପୋରେଟ୍ ପ୍ରକ୍ସି ପଛରେ ଚାଲୁଥିବା ୱାର୍କର୍ ପ୍ରଦାତାଙ୍କ ନିକଟକୁ ଯାଉଥିବା ଅନୁରୋଧରେ ସେହି ପଥ ଆବଶ୍ୟକ କରେ।

OAuth 1.0 ରେ ମଧ୍ୟ ଉପଭୋକ୍ତା ପ୍ରବେଶ ଅନୁମୋଦନ କରିବା ପୂର୍ବରୁ ସର୍ଭର ପକ୍ଷରେ ଅନୁରୋଧ-ଟୋକେନ୍ ପଦକ୍ଷେପ ଥାଏ। OAuth 2.0 ର ଅନୁମତି-କୋଡ୍ ପ୍ରବାହରେ କଲବ୍ୟାକ୍ ପରେ ନିଜସ୍ୱ ଟୋକେନ୍ ବିନିମୟ ଥାଏ। ସଠିକ୍ କ୍ରମ ରଣନୀତି ଉପରେ ନିର୍ଭର କରେ, କିନ୍ତୁ ବ୍ରାଉଜର ଏବଂ ଆପ୍ଲିକେସନ୍ ସର୍ଭର ଅଲଗା ଆରମ୍ଭ ବିନ୍ଦୁ ହୋଇ ରହନ୍ତି।

କ୍ଲାଏଣ୍ଟର ବିନ୍ୟାସ ଖୋଜନ୍ତୁ

ରଣନୀତିକୁ ଅନୁସରଣ କରି ସେହି HTTP କ୍ଲାଏଣ୍ଟ ପର୍ଯ୍ୟନ୍ତ ଯାଆନ୍ତୁ ଯାହା ଏହାର ଟୋକେନ୍ ଏବଂ ପ୍ରଦାତାଙ୍କ API ଅନୁରୋଧ ପଠାଏ। ସେହି କ୍ଲାଏଣ୍ଟର ଡକ୍ୟୁମେଣ୍ଟେଡ୍ ପ୍ରକ୍ସି ବିକଳ୍ପ ବ୍ୟବହାର କରନ୍ତୁ। କେତେକ ରଣନୀତି କ୍ଲାଏଣ୍ଟ ବିକଳ୍ପ OAuth ଲାଇବ୍ରେରୀକୁ ପଠାନ୍ତି; ଅନ୍ୟମାନେ ଏହାର ତଳେ HTTP ସଂଯୋଗ ବିନ୍ୟାସ କରନ୍ତି। ଗୋଟିଏ ରଣନୀତି ଗ୍ରହଣ କରୁଥିବା ବିକଳ୍ପ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ସାଧାରଣ OmniAuth ବିକଳ୍ପ ନୁହେଁ।

ପ୍ରଦାତାଙ୍କ ଅନୁମତି, ଟୋକେନ୍ ଏବଂ କଲବ୍ୟାକ୍ URL ସେମାନଙ୍କ ପ୍ରକୃତ ସେବାକୁ ବର୍ଣ୍ଣନା କରିବାକୁ ଦିଅନ୍ତୁ। ଆଉଟବାଉଣ୍ଡ୍ ପ୍ରକ୍ସି ପ୍ରଦାତାଙ୍କ ନିକଟକୁ ପହଞ୍ଚିବା ପାଇଁ ପରିବହନ ସେଟିଂ, ଏହା କଲବ୍ୟାକ୍ ଠିକଣାର ବିକଳ୍ପ ନୁହେଁ କିମ୍ବା OAuth ଅନୁରୋଧ ପାରାମିଟରରେ ଯୋଡ଼ିବାକୁ ଥିବା କ୍ଷେତ୍ର ନୁହେଁ।

ଲଗଇନ୍ ଟ୍ରେସ୍ କରିବା ସମୟରେ ଶେଷ ସମ୍ପୂର୍ଣ୍ଣ ପଦକ୍ଷେପ ଚିହ୍ନଟ କରନ୍ତୁ। ଦେଖାଯାଇଥିବା ପ୍ରଦାତା ଲଗଇନ୍ ପୃଷ୍ଠା ପ୍ରମାଣ କରେ ଯେ ବ୍ରାଉଜରର ପଥ କାମ କରିଛି। Rails ଗ୍ରହଣ କରିଥିବା କଲବ୍ୟାକ୍ ପ୍ରମାଣ କରେ ଯେ ବ୍ରାଉଜର ଫେରିଛି। ପରବର୍ତ୍ତୀ ଟୋକେନ୍ ଅନୁରୋଧ ହେଉଛି Rails ପ୍ରକ୍ରିୟାରୁ ଆସୁଥିବା ପ୍ରକ୍ସି ସଂଯୋଗ, ଚ୍ୟାଲେଞ୍ଜ କିମ୍ବା ପ୍ରଦାତାଙ୍କ ପ୍ରତିକ୍ରିୟା ଯାଞ୍ଚ କରିବାର ସ୍ଥାନ।