Прокси-запросы oAuth между потребителем и провайдером

Question

у нас есть проблема с тем, как прокси-запросы oAuth 1.0a с промежуточным прокси-сервером между потребителем (клиентом) и провайдером (сервер oAuth).

В принципе это выглядитнапример:

------------
| Consumer |
------------
      |
      V
------------
|  Proxy   |
------------
      |
      V
----------------
| oAuth Server |
----------------

Возможная проблема, о которой мы думаем, заключается в том, что при повторной отправке HTTP-запроса на наш oAuth-сервер Apache прокси-сервера устанавливает для некоторых заголовков запроса разные значения, икогда запрос подписан на сервере oAuth, подписи не будут совпадать.

Знаете ли вы, что прокси-сервер повторно отправляет запрос без каких-либо изменений, поэтому подпись будет действительной в случае oAuth?

Еще один вариант, о котором мы думаем, - это заменить измененные заголовки на сервере oAuth перед подписанием и, таким образом, изменить запрос так, чтобы он отображался не из прокси-сервера, а напрямую из клиента.Как вы думаете, это возможно в PHP - заменить заголовки запроса, например, переменные $ _SERVER?

Спасибо

Answer 1

Оказалось, что единственным HTTP-заголовком, который используется клиентом при подписании запроса, является HTTP-заголовок HOST. Это не включает специальные заголовки OAuth в случае, если параметры oAuth передаются как заголовки OAuth.

Таким образом, единственное, что должен сделать прокси-сервер, это отправить нам заголовок HOST, который использовался клиентом для подписания запроса.

Пример: Предположим, что если клиент (потребитель) делает HTTP-запрос к прокси-серверу для получения токена, он отправляет запрос следующей конечной точке:

http://proxy.com/oauth/request

В этом случае запрос будет выглядеть примерно так, а заголовок Host со значением proxy.com будет использоваться при подписании запроса.

POST /oauth/request HTTP/1.1
Host: proxy.com

Предположим, что конечная точка, в которой наш сервер oAuth ожидает запросы:

http://oursite.com/oauth/request

Когда прокси-сервер получает запрос, он может отправить его на нашу конечную точку и дать нам значение proxy.com в дополнительном заголовке HTTP, который мы можем использовать для подписи запроса на нашей стороне, вместо использования исходного заголовка HOST, который будет быть со значением oursite.com