Праћење 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 процеса.