ప్రాక్సీ ద్వారా 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 యొక్క అధికార-కోడ్ ప్రవాహంలో కాల్‌బ్యాక్ తర్వాత దాని సొంత టోకెన్ మార్పిడి ఉంటుంది. సరైన క్రమం వ్యూహంపై ఆధారపడి ఉంటుంది, కానీ బ్రౌజర్ మరియు అప్లికేషన్ సర్వర్ వేర్వేరు ప్రారంభ బిందువులుగానే ఉంటాయి.

క్లయింట్ కాన్ఫిగరేషన్‌ను కనుగొనండి

వ్యూహాన్ని అనుసరించి దాని టోకెన్ మరియు ప్రొవైడర్ API అభ్యర్థనలను పంపే HTTP క్లయింట్ వరకు వెళ్లండి. ఆ క్లయింట్ యొక్క డాక్యుమెంట్ చేసిన ప్రాక్సీ ఎంపికను ఉపయోగించండి. కొన్ని వ్యూహాలు క్లయింట్ ఎంపికలను OAuth లైబ్రరీకి అందిస్తాయి; మరికొన్ని దాని కింద HTTP కనెక్షన్‌ను కాన్ఫిగర్ చేస్తాయి. ఒక వ్యూహం ఆమోదించే ఎంపిక ఆటోమేటిక్‌గా భాగస్వామ్య OmniAuth ఎంపిక కాదు.

ప్రొవైడర్ యొక్క అధికార, టోకెన్ మరియు కాల్‌బ్యాక్ URL లు దాని నిజమైన సేవలను వివరించనివ్వండి. అవుట్‌బౌండ్ ప్రాక్సీ ప్రొవైడర్‌ను చేరుకోవడానికి రవాణా సెట్టింగ్, ఇది కాల్‌బ్యాక్ చిరునామాకు ప్రత్యామ్నాయం కాదు మరియు OAuth అభ్యర్థన పారామితులకు జోడించే ఫీల్డ్ కాదు.

లాగిన్‌ను ట్రేస్ చేస్తున్నప్పుడు చివరిగా పూర్తైన దశను గుర్తించండి. చూపిన ప్రొవైడర్ లాగిన్ పేజీ బ్రౌజర్ మార్గం పనిచేసిందని నిరూపిస్తుంది. Rails స్వీకరించిన కాల్‌బ్యాక్ బ్రౌజర్ తిరిగి వచ్చిందని నిరూపిస్తుంది. తదుపరి టోకెన్ అభ్యర్థనే Rails ప్రక్రియ నుండి వచ్చే ప్రాక్సీ కనెక్షన్, సవాలు లేదా ప్రొవైడర్ ప్రతిస్పందనను పరిశీలించే స్థలం.