2011-08-08 2 views
1

Мне было поручено обслуживать файл изображения с нашего сервера, на который ссылается документ html, находящийся на нескольких других серверах. Для остроумия:Можно ли надежно узнать, откуда возникла HTTP-запрос без сценариев?

файла на foo.com:
<img src='http://bar.com/image.jpg'>

Когда пользователь переходит к foo.com, он отображает изображение с нашего сервера, bar.com. (Фактически это отправляет другое изображение, основанное на том, что веб-сайт сделал запрос.)

Но вот улов: они хотят, чтобы посетители определенных компаний могли получать файл (в настоящее время идентифицируется доменным именем сервера, но это не требование).

В идеальном мире вы просто посмотрите HTTP_REFERER и, если он находится в одобренном списке, откройте файл. Но, как известно, не каждый пользовательский агент поставляет HTTP_REFERER, и он может быть подделан в любом случае.

Было бы лучше не запускать javascript или php, но это то, что мы можем даже без сценариев?

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

Если нет, то как бы вы приблизились к нему с помощью PHP?

+0

Вы говорите о веб-сайте, загружающем файл? Файлы загружаются клиентами в браузерах, а не сайтами. Каждый HTTP-запрос, будь то для страницы, сценарий, изображение и т. Д., Представляет собой отдельный запрос, исходящий из браузера пользователя, а не веб-сайт, который они просматривают. –

+0

Ну, серверные загрузки по-прежнему возможны. Но это похоже на то, что OP просто хочет спросить «что хорошего способа аутентификации загрузок» в любом случае – Evert

+0

Да, я понимаю, что пользовательские агенты выполняют загрузку, и в конечном итоге проблема в том, что им нельзя доверять HTTP_REFERER , Я не хочу проверять подлинность загрузок; Я хочу, чтобы любой публичный пользователь из «белого списка» сервера мог просматривать изображение, но никаких других серверов. – pbarney

ответ

3

Вы имеете какое-либо влияние на веб-приложения одобренных компаний? Если это так, я могу подумать о двух способах достижения этой цели.

Используя ваши примеры Foo/бар, где bar.com ваш сервер, и foo.com является одним из ваших утвержденных компаний:

1) Вместо того, чтобы браузер делает запрос на сервер, у них сделать запрос обработчику изображения на foo.com, который, в свою очередь, делает HTTP-запрос на ваш сервер за кулисами и возвращает содержимое изображения обратно клиенту. Исходящий IP-адрес Foo будет на белом списке на вашем сервере, поэтому все запросы на самом деле поступают с IP-адреса Foo.Клиент увидит:

<img src="http://foo.com/imagehandler.php" /> 

2) Гораздо сложнее, но если Foo не может сделать запрос к серверам, Foo может поставить специальный хэш в строке запроса тега изображений, так что, когда браузер делает запрос на ваш сервер, вы узнаете, что URL-адрес был создан Foo. Вам понадобится секретный ключ на сервере Foo, чтобы он мог вычислять хэш.

Я бы предположил, что хэш будет рассчитываться на основе комбинации IP-адреса браутера, текущей даты/времени и закрытого ключа.

Так что браузер будет делать запрос на foo.com/default.php и Foo будет строить следующий тег изображения для браузера:

<img src="http://bar.com/imagehandler.php?hash=393923A423B423F234C34" /> 

, где это число представляет собой соответствующий хэш. В коде обработчика изображения Bar вам нужно будет пересчитать этот хэш на основе закрытого ключа, который известен только Foo и Bar, IP-адрес, который является частью запроса GET, и текущую дату/время. Если хеш совпадает, вы можете быть уверены, что браузер смотрит на сайт foo.com, и вы можете вернуть содержимое изображения.

3

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

Что вы хотите, так это разрешить доступ к изображению только определенным людям. Есть два способа сделать это:

  • фильтра запроса IP-адрес, если это известно
  • требует заверенного/куков заголовка сеанса/авторизации, то есть защитить пароль изображения

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

(на стороне клиента) Javascript не будет здесь вообще использоваться.