Адсочванне ўваходу праз OmniAuth праз проксі

Карыстальнік націскае «Увайсці», трапляе на старонку праўніка і вяртаецца ў Rails. Наступны крок усё яшчэ можа не ўдацца, бо ён пачынае новае злучэнне з сервера Rails.

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

Браўзер выконвае перанакіраванне аўтарызацыі, выкарыстоўваючы ўласныя сеткавыя налады. Rails выконвае абмен токена па зваротным канале праз HTTP-кліент, абраны ўсталяванай стратэгіяй OmniAuth. Працоўны працэс за карпаратыўным проксі мае патрэбу ў гэтым маршруце для сваіх запытаў да праўніка.

У OAuth 1.0 таксама ёсць крок запыту токена на баку сервера перад тым, як карыстальнік дазволіць доступ. У патоку кода аўтарызацыі OAuth 2.0 ёсць уласны абмен токена пасля зваротнага выкліку. Дакладная паслядоўнасць залежыць ад стратэгіі, але браўзер і сервер праграмы застаюцца рознымі пунктамі адпраўлення.

Знайдзіце налады кліента

Прасочвайце стратэгію да HTTP-кліента, які адпраўляе яе токен і запыты да API праўніка. Выкарыстоўвайце дакументаваную опцыю проксі гэтага кліента. Некаторыя стратэгіі перадаюць опцыі кліента ў бібліятэку OAuth; іншыя наладжваюць HTTP-злучэнне пад ёй. Опцыя, якую прымае адна стратэгія, не становіцца аўтаматычна агульнай опцыяй OmniAuth.

Хай URL-адрасы аўтарызацыі, токена і зваротнага выкліку праўніка апісваюць яго рэальныя сэрвісы. Выходны проксі — гэта налада транспарту для доступу да праўніка, а не замена адраса зваротнага выкліку і не поле, якое дадаюць у параметры запыту OAuth.

Пры адсочванні ўваходу пазначайце апошні завершаны крок. Паказаная старонка ўваходу праўніка даказвае, што маршрут браўзера працаваў. Атрыманы Rails зваротны выклік даказвае, што браўзер вярнуўся. Наступны запыт токена — гэта месца, дзе варта шукаць праксі-злучэнне, выклік або адказ праўніка ад працэсу Rails.