Spåra en OmniAuth-inloggning genom en proxy

Användaren klickar på ”Logga in”, når leverantörens sida och återvänder till Rails. Nästa steg kan ändå misslyckas eftersom det öppnar en ny anslutning från Rails-servern.

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

Webbläsaren följer auktoriseringsomdirigeringen med sin egen nätverkskonfiguration. Rails utför tokenutbytet på bakkanalen med den HTTP-klient som den installerade OmniAuth-strategin väljer. En arbetare bakom en företagsproxy behöver den vägen på sina förfrågningar till leverantören.

OAuth 1.0 har också ett steg med förfrågningstoken på serversidan innan användaren auktoriserar åtkomst. OAuth 2.0:s auktoriseringskodflöde har sitt eget tokenutbyte efter callbacken. Den exakta ordningen beror på strategin, men webbläsaren och applikationsservern förblir olika utgångspunkter.

Hitta klientens konfiguration

Följ strategin till den HTTP-klient som skickar dess token och förfrågningarna till leverantörens API. Använd den dokumenterade proxyinställningen för den klienten. Vissa strategier skickar klientinställningar vidare till ett OAuth-bibliotek; andra konfigurerar en HTTP-anslutning under det. En inställning som en strategi accepterar är inte automatiskt en gemensam OmniAuth-inställning.

Låt leverantörens auktoriserings-, token- och callback-URL:er beskriva dess faktiska tjänster. Den utgående proxyn är en transportinställning för att nå leverantören, inte en ersättningsadress för callback och inte ett fält som läggs till i OAuth-förfrågans parametrar.

När du spårar en inloggning, markera det senast slutförda steget. En visad inloggningssida hos leverantören bevisar att webbläsarens väg fungerade. En callback som Rails tar emot bevisar att webbläsaren återvände. Den efterföljande tokenförfrågan är stället att undersöka för en proxyanslutning, en utmaning eller ett svar från leverantören från Rails-processen.