Следење на најавувањето 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.