Rastrear um login OmniAuth através de um proxy

O usuário clica em «Entrar», chega à página do provedor e volta ao Rails. O passo seguinte ainda pode falhar porque abre uma nova conexão a partir do servidor Rails.

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

O navegador segue o redirecionamento de autorização com a sua própria configuração de rede. O Rails realiza a troca de token pelo canal traseiro com o cliente HTTP escolhido pela estratégia OmniAuth instalada. Um worker a correr atrás de um proxy corporativo precisa dessa rota nos seus pedidos ao provedor.

O OAuth 1.0 também tem um passo de token de pedido no servidor antes de o utilizador autorizar o acesso. O fluxo de código de autorização do OAuth 2.0 tem a sua própria troca de token após o callback. A sequência exata depende da estratégia, mas o navegador e o servidor de aplicações continuam a ser pontos de partida distintos.

Localize a configuração do cliente

Siga a estratégia até ao cliente HTTP que envia o token e os pedidos à API do provedor. Use a opção de proxy documentada desse cliente. Algumas estratégias passam as opções do cliente a uma biblioteca OAuth; outras configuram uma ligação HTTP por baixo. Uma opção aceite por uma estratégia não é automaticamente uma opção partilhada do OmniAuth.

Deixe os URL de autorização, token e callback do provedor descreverem os seus serviços reais. O proxy de saída é uma definição de transporte para chegar ao provedor, não um endereço de callback substituto nem um campo a acrescentar aos parâmetros do pedido OAuth.

Ao rastrear um login, marque o último passo concluído. Uma página de login do provedor apresentada prova que a rota do navegador funcionou. Um callback recebido pelo Rails prova que o navegador regressou. O pedido de token seguinte é o ponto onde inspecionar uma ligação proxy, um desafio ou uma resposta do provedor proveniente do processo Rails.