ഒരു പ്രോക്സി വഴി OmniAuth ലോഗിൻ ട്രേസ് ചെയ്യൽ

ഉപയോക്താവ് “സൈൻ ഇൻ” ക്ലിക്ക് ചെയ്ത് ദാതാവിന്റെ പേജിൽ എത്തി Rails-ലേക്ക് മടങ്ങുന്നു. അടുത്ത ഘട്ടം ഇപ്പോഴും പരാജയപ്പെടാം, കാരണം അത് Rails സെർവറിൽ നിന്ന് പുതിയ കണക്ഷൻ തുടങ്ങുന്നു.

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

ബ്രൗസർ അതിന്റെ സ്വന്തം നെറ്റ്വർക്ക് കോൺഫിഗറേഷൻ ഉപയോഗിച്ച് അനുമതി റീഡയറക്ട് പിന്തുടരുന്നു. ഇൻസ്റ്റാൾ ചെയ്ത OmniAuth സ്ട്രാറ്റജി തിരഞ്ഞെടുക്കുന്ന HTTP ക്ലയന്റ് ഉപയോഗിച്ച് Rails ബാക്ക് ചാനൽ ടോക്കൺ കൈമാറ്റം നടത്തുന്നു. കോർപ്പറേറ്റ് പ്രോക്സിക്ക് പിന്നിൽ പ്രവർത്തിക്കുന്ന ഒരു വർക്കർക്ക് ദാതാവിലേക്കുള്ള അഭ്യർത്ഥനകളിൽ ആ പാത ആവശ്യമാണ്.

OAuth 1.0-ൽ ഉപയോക്താവ് പ്രവേശനം അനുവദിക്കുന്നതിന് മുമ്പ് സെർവർ വശത്ത് അഭ്യർത്ഥന-ടോക്കൺ ഘട്ടവുമുണ്ട്. OAuth 2.0-ന്റെ അനുമതി-കോഡ് ഫ്ലോയ്ക്ക് കോൾബാക്കിന് ശേഷം സ്വന്തം ടോക്കൺ കൈമാറ്റമുണ്ട്. കൃത്യമായ ക്രമം സ്ട്രാറ്റജിയെ ആശ്രയിച്ചിരിക്കുന്നു, പക്ഷേ ബ്രൗസറും ആപ്ലിക്കേഷൻ സെർവറും വ്യത്യസ്ത ആരംഭ പോയിന്റുകളായി തുടരുന്നു.

ക്ലയന്റിന്റെ കോൺഫിഗറേഷൻ കണ്ടെത്തുക

സ്ട്രാറ്റജിയെ അതിന്റെ ടോക്കണും ദാതാവിന്റെ API അഭ്യർത്ഥനകളും അയയ്ക്കുന്ന HTTP ക്ലയന്റിലേക്ക് പിന്തുടരുക. ആ ക്ലയന്റിന്റെ രേഖപ്പെടുത്തിയ പ്രോക്സി ഓപ്ഷൻ ഉപയോഗിക്കുക. ചില സ്ട്രാറ്റജികൾ ക്ലയന്റ് ഓപ്ഷനുകൾ OAuth ലൈബ്രറിയിലേക്ക് കൈമാറുന്നു; മറ്റുള്ളവ അതിനടിയിൽ ഒരു HTTP കണക്ഷൻ കോൺഫിഗർ ചെയ്യുന്നു. ഒരു സ്ട്രാറ്റജി സ്വീകരിക്കുന്ന ഓപ്ഷൻ സ്വയമേവ ഒരു പൊതു OmniAuth ഓപ്ഷനല്ല.

ദാതാവിന്റെ അനുമതി, ടോക്കൺ, കോൾബാക്ക് URL-കൾ അവയുടെ യഥാർത്ഥ സേവനങ്ങളെ വിവരിക്കട്ടെ. ഔട്ട്ബൗണ്ട് പ്രോക്സി ദാതാവിനെ സമീപിക്കാനുള്ള ഗതാഗത ക്രമീകരണമാണ്, അത് കോൾബാക്ക് വിലാസത്തിന് പകരമല്ല, OAuth അഭ്യർത്ഥന പരാമീറ്ററുകളിൽ ചേർക്കേണ്ട ഒരു ഫീൽഡുമല്ല.

ലോഗിൻ ട്രേസ് ചെയ്യുമ്പോൾ അവസാനം പൂർത്തിയായ ഘട്ടം അടയാളപ്പെടുത്തുക. ദാതാവിന്റെ ലോഗിൻ പേജ് കാണിച്ചാൽ ബ്രൗസറിന്റെ പാത പ്രവർത്തിച്ചുവെന്ന് തെളിയുന്നു. Rails സ്വീകരിച്ച കോൾബാക്ക് ബ്രൗസർ മടങ്ങിയെന്ന് തെളിയിക്കുന്നു. തുടർന്നുള്ള ടോക്കൺ അഭ്യർത്ഥനയാണ് Rails പ്രോസസിൽ നിന്നുള്ള പ്രോക്സി കണക്ഷൻ, വെല്ലുവിളി, ദാതാവിന്റെ പ്രതികരണം എന്നിവ പരിശോധിക്കേണ്ട സ്ഥലം.