Назад |
Перейти на главную страницу
Способы перенаправления на служебный сервер
У меня есть ситуация, когда мне нужно облегчить загрузку файлов размером до 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 на служебный сервер.
Вопрос в том, как лучше всего скрыть служебный сервер от клиента, не проталкивая данные загрузки файла через веб-сервер? Вот идеи, которые я решил попробовать:
- DNS-псевдоним служебного сервера с поддоменом. Это, вероятно, решит мою проблему с междоменными сценариями, но я не уверен, помогает ли это защитить служебный сервер. Может быть, я могу проверить файл cookie аутентификации веб-сервера с служебного сервера?
- Правило перезаписи в конфигурации Apache веб-сайта. Я не понимаю, как это влияет на то, куда на самом деле будут маршрутизироваться данные POST.
- Перенаправление в конфигурации Apache веб-сайта. Я не уверен, смогу ли я скрыть URL-адрес служебного сервера от пользователя с перенаправлением.
- Перенаправление с кода контроллера веб-сайта. Та же проблема, что и №3, но я подумал, что это может быть лучше, чем №3, поскольку он будет передавать запрос через уровень аутентификации PHP.
- Что-то лучше??
Ноты:
- Необычная конфигурация служебного сервера - это функция пересечения доступного программного обеспечения для служебных программ, которые ему необходимо выполнять.
- Служебный сервер НЕ является особо ценной целью для серьезных неприятностей. Было бы достаточно иметь эквивалент безопасности, как запирать входную дверь, но я бы не хотел оставлять ключ под ковриком.
Вы не можете скрыть URL-адрес служебного сервера от клиента, не проксируя его на веб-сервере. Я бы установил общий ключ как на веб-сервере, так и на служебном сервере, и действовал бы следующим образом:
Веб-сервер рисует ссылку или перенаправляет клиента на служебный сервер со следующими параметрами:
- аутентифицированное имя пользователя
- отметка времени создания (или перенаправления) ссылки
- клиентский ip
- подпись (предыдущие 3 значения хешируются с помощью общего ключа)
На служебном сервере вы проверяете, что:
- Полученная подпись верна (повторный хеш с общим ключом)
- IP-адрес клиента такой же, как указано в параметре
- время, прошедшее с момента получения метки времени в параметре, меньше разумного (10-20 секунд должно быть достаточно, учитывая, что и веб-сервер, и служебный сервер используют один и тот же источник времени)
Если все проверки пройдены, вы можете принять пользователя как прошедшего проверку подлинности (потому что вы доверяете общему ключу), начать сеанс и нарисовать форму для загрузки файла.