L'utente fa clic su «Accedi», raggiunge la pagina del provider e torna a Rails. Il passaggio successivo può comunque fallire perché apre una nuova connessione dal server Rails.

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

Il browser segue il reindirizzamento di autorizzazione con la propria configurazione di rete. Rails esegue lo scambio di token sul canale posteriore con il client HTTP scelto dalla strategia OmniAuth installata. Un worker in esecuzione dietro un proxy aziendale ha bisogno di quel percorso nelle richieste verso il provider.

Anche OAuth 1.0 ha un passaggio di token di richiesta lato server prima che l'utente autorizzi l'accesso. Il flusso con codice di autorizzazione di OAuth 2.0 ha il proprio scambio di token dopo il callback. La sequenza esatta dipende dalla strategia, ma il browser e il server applicativo restano punti di partenza distinti.

Individuare la configurazione del client

Seguite la strategia fino al client HTTP che invia il suo token e le richieste all'API del provider. Usate l'opzione proxy documentata di quel client. Alcune strategie passano le opzioni del client a una libreria OAuth; altre configurano una connessione HTTP al di sotto. Un'opzione accettata da una strategia non è automaticamente un'opzione OmniAuth condivisa.

Lasciate che gli URL di autorizzazione, token e callback del provider descrivano i suoi servizi reali. Il proxy in uscita è un'impostazione di trasporto per raggiungere il provider, non un indirizzo di callback sostitutivo né un campo da aggiungere ai parametri della richiesta OAuth.

Quando tracciate un accesso, segnate l'ultimo passaggio completato. Una pagina di accesso del provider visualizzata dimostra che il percorso del browser ha funzionato. Un callback ricevuto da Rails dimostra che il browser è tornato. La successiva richiesta di token è il punto in cui controllare una connessione proxy, una sfida o una risposta del provider dal processo Rails.

Articoli correlati