Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Защита изображений от hotlinking
Форумы портала PHP.SU » PHP » Программирование на PHP » Защита изображений от hotlinking

Страниц (1): [1]
 

1. Viper - 15 Декабря, 2010 - 08:09:52 - перейти к сообщению
Собственно меня интересует больше подход к решению проблемы.
Не так давно в своем проекте столкнулся с такой проблемой что любой юзер может брать ссылку на изображения с моего сайта и тулить на свой и все чудесно работавает.

В связи с этим потерроризировал гугль и нашел статейку http://www[dot]alistapart[dot]com/articles/hotlinking/
Имеет ли смысл отслеживать рефереры, если их можно банально подделать?

В проекте картинки выводятся таким образом
<a href="http://site/images/12345[dot]jpg"><img src="http://site/images/thumb_12345.jpg" /></a>. Т.е. как в обычной галерее. Пропускать каждую картинку через некий скрипт проверки имеет ли смысл? Или забить на это и разрешить hotlinking и бешенный трафик на хост?!
2. EuGen - 15 Декабря, 2010 - 09:24:38 - перейти к сообщению
HTTP REFERER подделать - очень легко.
Так что я думаю, проще защитить материалы авторским правом (хотя в нашей стране все равно будут просто красть эти материалы) - так хотя бы формально материалы будут Вашими.
Если на сайте что-то действительно ценное, что хочется защитить - возможно, стоит делать этот контент закрытым (например, для пользователей, которые должны что-то сделать, чтобы его увидеть, а потому не станут раздавать его направо и налево)
3. Phantik - 15 Декабря, 2010 - 09:33:32 - перейти к сообщению
А если ставить на картинки водяные знаки с адресом вашего сайта? Пускай либо фотошопят картинки либо рекламируют ваш сайт.
4. Мелкий - 15 Декабря, 2010 - 09:57:28 - перейти к сообщению
Реферер подделывается легко, но для этого этому самому юзеру придётся гуглить, так что определённый круг людей отбросит.

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

Я ведь правильно понял, что проблема не в том, что тырят картинки, а в том, что у вас паразитный трафик?
5. Uchkuma - 15 Декабря, 2010 - 12:04:24 - перейти к сообщению
Мне кажется, проблема высосана из пальца. Какой смысл хотлинка? Экономия трафика! Чтобы подделать реферера, что нужно? Отправить правильный заголовок. Заголовок отправляет либо браузер пользователя, либо скрипт. В браузер пользователя мы вмешаться не сможем, поэтому заголовки придется отправлять скриптом на стороне сервера. Получается, что трафик один хрен пойдет через наш сервер и url изображения должен указывать на наш скрипт, а не на сторонний сайт. А это уже не фига не хотлинк.

Поправьте меня, если я что-то не так понимаю.
6. OrmaJever - 15 Декабря, 2010 - 12:36:36 - перейти к сообщению
Мелкий пишет:
А дальше - только замысловатые методы, типа приписывать к ссылке на картинку ключик со сроком жизни в час

кстате а вот это вариант! Можно зделать так как отдаются файлы на депозит. Сылка всегда динамическая. Тоестьсам скачал дал другу а сылка уже не работает.
7. JustUserR - 15 Декабря, 2010 - 13:03:13 - перейти к сообщению
Viper В качестве варината решения осуществляющего защиты от возможности запроса пользователем изображений из каталогов распооложения некоторого web-сайта при включении компонента его запроса к другом ресурсе возможно использования следующих вариатнов - в качестве возможного простого решения допустимо включение системы авторизации на оригинальном web-сайта и обеспечению передачи запрошенных объектов изображений посредством неявного вызываемого PHP-скрипта при соответствующей конфигурации alias-инга и действенного перенаправления обслуживающего его web-сервера - в качестве более качественного варианта защиты допустимо применение такого управляющего генерацией пользовательских документов HTTP-ответа PHP-скрипта включающего синхронизацию по уникальному ключу с элементам HTML-страницы осуществляющими запрос соответствущего изображения на ресурсе
8. Viper - 15 Декабря, 2010 - 13:04:37 - перейти к сообщению
Мелкий пишет:
Я ведь правильно понял, что проблема не в том, что тырят картинки, а в том, что у вас паразитный трафик?

Именно что траффик. На саму то картинку ватермарк вешается.

Uchkuma т.е. с вашей точки зрения все это: "С базуки по мухе"?

Мелкий пишет:
А дальше - только замысловатые методы
Не хотелось бы слишком усложнять и себе и людям жизнь. Просто картинки все равно в общем доступе, а и попорайт сайта на них весит.
9. Uchkuma - 15 Декабря, 2010 - 17:46:39 - перейти к сообщению
Viper пишет:
т.е. с вашей точки зрения все это: "С базуки по мухе"?
Сделайте обычную защиту от хотлинка. С помощью htaccess или еще как. Если "левый" трафик был, то он сразу "отвалится". Если конечно левый трафик не связан с грабингом вашего сайта.
10. JustUserR - 15 Декабря, 2010 - 20:57:09 - перейти к сообщению
Viper пишет:
Именно что траффик. На саму то картинку ватермарк вешается
Предполагаемые в преыдущем сообщении вариант осуществления защиты от возможности прямого доступа к элементам изображений на вашем web-узле при включении их с состав сторонних HTML-страниц - включает проведения реального HTTP-запроса на целевой сервер при проведнии обработки компонента включения изображения браузером - однако обеспечивает предотвращения передачи содержимого собственного файловго объекта изображения
11. Invert - 16 Декабря, 2010 - 05:30:31 - перейти к сообщению
Viper пишет:
Собственно меня интересует больше подход к решению проблемы.

Использовал 2 способа, могу немного объяснить.

1: Через .htaaccess - просто и сердито. Если чужой реферер - отдаем другое изображение, на котором написано: "Все изображения находятся на сайте www.bla-bla.ru". Не забудьте указать, что при пустом реферере нельзя блокировать изображение, некоторые пользователи открывают изображения отдельно. (Если на серваке установлен Nginx: прописывать нужно в его конфиге, возможностей там поболее.)

2: Через особый PHP скрипт. Тут немного сложнее, т.к. придется создать целый модуль, который будет проверять реферер.

Этот вариант имеет недостатки:
- время на разработку и отладку.
- нагрузка на хостинг\сервер, создаваемая скриптом (а также висящие процессы от пользователей с медленным соединением).
- еще касательно Nginx'а, но это не столь важно.

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

OrmaJever пишет:
кстате а вот это вариант! Можно зделать так как отдаются файлы на депозит. Сылка всегда динамическая. Тоестьсам скачал дал другу а сылка уже не работает.

Такую ссылку не вставишь в тело страницы, и как правило у них "срок жизни".
Uchkuma пишет:
Мне кажется, проблема высосана из пальца. Какой смысл хотлинка?

Ну, это с какой стороны посмотреть. Если у вас хостинг за 2 у.е. в месяц и 15 хостов в сутки, то да, беспокоится не о чем. А если 10 тысяч и паразиты создают доп. нагрузку на сервер, то просто необходимо от них избавиться.
(Добавление)
Мелкий пишет:
Но в таком случае умрёт кэширование на стороне браузера, так что ещё спорно, будет ли выигрыш по трафику.

Кэширование не умрет, если правильно сделать.
Скриптом возвращаем такие заголовки, какие нужно и браузер даже не поймет, что файл выдается скриптом. А если хорошо постараться, то и пользователь не поймет.

http://site[dot]ru/catalog/directory/imagename[dot]jpg - Прямая ссылка? Нет, скрипт получает через URL три GET параметра: название каталога изображений, папка изображений и имя изображения. И возвращает даже не файл с .jpg расширением, а заранее созданный оптимизированный файл imagename.cache, с ватермаркой и требуемого размера.
12. Uchkuma - 16 Декабря, 2010 - 09:20:45 - перейти к сообщению
Invert пишет:
Ну, это с какой стороны посмотреть. Если у вас хостинг за 2 у.е. в месяц и 15 хостов в сутки, то да, беспокоится не о чем.
Вы невнимательно прочитали мой пост.
Invert пишет:
Кэширование не умрет, если правильно сделать.
И пост Мелкого тоже. Там шла речь о добавлении к имени файла ключика.
Invert пишет:
Скриптом возвращаем такие заголовки, какие нужно и браузер даже не поймет, что файл выдается скриптом.
По большому счету браузеру вообще все равно, скриптом файл отдается или напрямую из файловой системы. На кеширование это никак не влияет. А если не отдать правильные заголовки, изображение попросту браузером не будет отображено. Аналогично и для хотлинка не важно, какая будет ссылка на картинку, imagename.jpg или imagename.php.
13. Invert - 16 Декабря, 2010 - 09:29:43 - перейти к сообщению
Uchkuma пишет:
А если не отдать правильные заголовки, изображение попросту браузером не будет отображено. Аналогично и для хотлинка не важно, какая будет ссылка на картинку, imagename.jpg или imagename.php.

Ну да, я разве что-то другое сказал? Все дело в заголовках.
Uchkuma пишет:
И пост Мелкого тоже. Там шла речь о добавлении к имени файла ключика.

Что нам мешает ложить ключик в сессию или в куки? Правильно, ничего.
А если добавить ключ к УРЛ и ссылка на изображение будет постоянно находится на странице контента, то сами подумайте, что получится. Нелепо в этом случае говорить о защите изображения. Этот способ можно использовать только тогда, когда все остальные недоступны.
14. JustUserR - 16 Декабря, 2010 - 19:32:50 - перейти к сообщению
Invert пишет:
Использовал 2 способа, могу немного объяснить.
Описанные в предыдущих комментариях потока дискуссии варанты решения защиты изображений от прямого доступа обеспечивают обязательное включение пользователем целевого HTTP-запроса на web-ресурс с последующим осуществлением анализа информационных полей окружащей среды и расчета параметров доступа - в таком случае возможно конфигурирование объекта данных выходного HTTP-документа конролируемой генерации однако достаточно большое число целевых запросов обеспеичвают значительное количество сетевого траффикам - единственным варинтом обеспечивающим гарантированную защиту целевого содержимого является использование актвных пользовательских компонентов авторизации - которым в частности может выступать специализированных ActiveX-компонент в браузере Internet explorer с помощью которого возможно организовать защиту уровня клиентского компилируемого приложения

 

Powered by ExBB FM 1.0 RC1