ப்ராக்ஸி வழியாக 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 செயல்முறையிலிருந்து வரும் ப்ராக்ஸி இணைப்பு, சவால் அல்லது வழங்குநர் பதிலை ஆய்வு செய்யும் இடம்.