Urmărirea unei autentificări OmniAuth printr-un proxy

Utilizatorul face clic pe „Conectare”, ajunge pe pagina furnizorului și revine la Rails. Pasul următor poate eșua totuși, pentru că deschide o conexiune nouă de pe serverul Rails.

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

Browserul urmează redirecționarea de autorizare cu propria configurație de rețea. Rails efectuează schimbul de token pe canalul din spate cu clientul HTTP ales de strategia OmniAuth instalată. Un worker care rulează în spatele unui proxy corporativ are nevoie de acea rută la cererile către furnizor.

Și OAuth 1.0 are un pas de token de cerere pe server înainte ca utilizatorul să autorizeze accesul. Fluxul de cod de autorizare din OAuth 2.0 are propriul schimb de token după callback. Ordinea exactă depinde de strategie, dar browserul și serverul aplicației rămân puncte de plecare distincte.

Găsiți configurația clientului

Urmați strategia până la clientul HTTP care trimite tokenul și cererile către API-ul furnizorului. Folosiți opțiunea de proxy documentată a acelui client. Unele strategii transmit opțiunile clientului unei biblioteci OAuth; altele configurează o conexiune HTTP dedesubt. O opțiune acceptată de o strategie nu devine automat o opțiune OmniAuth comună.

Lăsați URL-urile de autorizare, token și callback ale furnizorului să descrie serviciile sale reale. Proxy-ul de ieșire este o setare de transport pentru a ajunge la furnizor, nu o adresă de callback de înlocuire și nici un câmp de adăugat la parametrii cererii OAuth.

Când urmăriți o autentificare, marcați ultimul pas finalizat. O pagină de conectare a furnizorului afișată dovedește că ruta browserului a funcționat. Un callback primit de Rails dovedește că browserul s-a întors. Cererea de token ulterioară este locul unde trebuie verificată o conexiune proxy, o provocare sau un răspuns al furnizorului din procesul Rails.