Назад | Перейти на главную страницу

Способы перенаправления на служебный сервер

У меня есть ситуация, когда мне нужно облегчить загрузку файлов размером до 200M на служебный сервер, который отделен от основного сервера веб-сайта. Вот моя конфигурация:

Authenticated
Client on
Public Internet
    /\    \
    |      \_____ 200M
    |            \_____  
    |                  \_____
    V                        V
Authenticating <------->  Utility Server
Web Site                  (EC2, Windows, Apache, Python, Django)
Server
(EC2 LAMP)

Мое текущее решение заключается в том, чтобы мой веб-сервер просто передавал URL-адрес EC2 сервера служебных программ и позволял клиенту напрямую связываться с сервером служебных программ. У этого есть два недостатка: он раскрывает URL-адрес неаутентифицированного служебного сервера и требует междоменных уловок на клиенте для маршрутизации загрузки POST на служебный сервер.

Вопрос в том, как лучше всего скрыть служебный сервер от клиента, не проталкивая данные загрузки файла через веб-сервер? Вот идеи, которые я решил попробовать:

  1. DNS-псевдоним служебного сервера с поддоменом. Это, вероятно, решит мою проблему с междоменными сценариями, но я не уверен, помогает ли это защитить служебный сервер. Может быть, я могу проверить файл cookie аутентификации веб-сервера с служебного сервера?
  2. Правило перезаписи в конфигурации Apache веб-сайта. Я не понимаю, как это влияет на то, куда на самом деле будут маршрутизироваться данные POST.
  3. Перенаправление в конфигурации Apache веб-сайта. Я не уверен, смогу ли я скрыть URL-адрес служебного сервера от пользователя с перенаправлением.
  4. Перенаправление с кода контроллера веб-сайта. Та же проблема, что и №3, но я подумал, что это может быть лучше, чем №3, поскольку он будет передавать запрос через уровень аутентификации PHP.
  5. Что-то лучше??

Ноты:

Вы не можете скрыть URL-адрес служебного сервера от клиента, не проксируя его на веб-сервере. Я бы установил общий ключ как на веб-сервере, так и на служебном сервере, и действовал бы следующим образом:

Веб-сервер рисует ссылку или перенаправляет клиента на служебный сервер со следующими параметрами:

  1. аутентифицированное имя пользователя
  2. отметка времени создания (или перенаправления) ссылки
  3. клиентский ip
  4. подпись (предыдущие 3 значения хешируются с помощью общего ключа)

На служебном сервере вы проверяете, что:

  1. Полученная подпись верна (повторный хеш с общим ключом)
  2. IP-адрес клиента такой же, как указано в параметре
  3. время, прошедшее с момента получения метки времени в параметре, меньше разумного (10-20 секунд должно быть достаточно, учитывая, что и веб-сервер, и служебный сервер используют один и тот же источник времени)

Если все проверки пройдены, вы можете принять пользователя как прошедшего проверку подлинности (потому что вы доверяете общему ключу), начать сеанс и нарисовать форму для загрузки файла.