Хотлинк мувиков

Кто как борется к хотлинком мувиков? Проблема в том что htaccess-ом защитится нелья, как я понял. Поэтому дрочерские форумы могут выкладывать прямые линки, и сосать трафик.
Вопрос:
- Кто нить пользовался коммерческими продуктами для предотвращения хотлинка мувиков? (знаю есть такие)
- по вебалайзеру на домене с мувиками в разделе рефереры - на первом месте - direct request - 16%. Значит ли это что меня уже имеют?

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

Потому что такое не проканает на мпг скорее всего..

почему ты так думаешь? любой файл прокатит, раз гиговые зипы отдавались

Simplex писал:

почему ты так думаешь? любой файл прокатит, раз гиговые зипы отдавались

Имеется в виду, что mgp не будут брать галереи, где вместо прямой ссылки на видео - скрипт какой-то стоит!

kodek писал:

Имеется в виду, что mgp не будут брать галереи, где вместо прямой ссылки на видео - скрипт какой-то стоит!

хм... ну можно же сделать что никто не поймет где прямая ссылка, а где реальный файл.

Simplex писал:

хм... ну можно же сделать что никто не поймет где прямая ссылка, а где реальный файл.

Возможно и так! Просто не понимаю, каков механизм будет. На сайте, наверное можно через сессии сделать. А как на галерее? Опять же - робот mgp'шный может без реферера зайти - чего ему выдаваться будет? Как его отличить от хотлинка в таком случае?

kodek писал:

Опять же - робот mgp'шный может без реферера зайти - чего ему выдаваться будет? Как его отличить от хотлинка в таком случае?

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

Simplex писал:

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

Ну хрен знает =)
Это уже какой-то редирект софт получается!

Simplex писал:

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

Бот много чего анализирует, а если это окажется не бот?
Блин неужели никто не зазищается от этого?

смотреть логи на предмет рефов на мувики с других хостов, и соответственно блокировать такое.

JW писал:

Бот много чего анализирует, а если это окажется не бот? Блин неужели никто не зазищается от этого?

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

Кстати, а где прочитать про сам механизм отдачи мувиков? Это я про то, что htaccess не спасает. Читал много раз на форуме. Поисковики лень дергать, если честно

pierx писал:

Кстати, а где прочитать про сам механизм отдачи мувиков? Это я про то, что htaccess не спасает. Читал много раз на форуме. Поисковики лень дергать, если честно

Цитата:

Why htaccess is not enough The htacces/mod_rewrite protection scheme, where the HTTP_REFERER field is checked, is being widely used for protecting images and some type of movies. Although it is quite succesfull (and some webmasters swear by it) it has it's shortcomings : It is by no means 100% secure (see demo), unless you dissalow the empty HTTP_REFERER, but in doing so, users will not be able to bookmark your pages. Does not protect many video file types, since not all media players sent the HTTP_REFERER field. The complexity of it's rules often leads to errored setups and frustrated users. Using cookies when a page is loaded, is false protection , since hotlinkers can easily use zero sized frames and pre-load the cookie. Furthermore, legitimate users who have turned their cookies or JavaScript off, are prevented from viewing your movies . One must also take into account, that JavaScript on HTML pages may resolve in your pages not getting listed or linked to by others.

взято тут
http://www.trafficguardian.com/hotlink/anti-hotlink.html

Да, я думал, надо проверять есть ли рефер нужный? нет? проверить куки. нет? тогда не отдавать.

Т.е. или то, или то - уменьшит число раздраженных юзеров. Хотя статистику надо собирать - у кого что включено/отключено при посещении гали/фришника

Да кстати, hotlink все таки неправильное слово тут. Скорее речь идет об direct request.. То есть когда вместо моей гали размещают прямые линки на мувики. Вот этот процент - 16% direct меня и беспокоит. Сюда наверно входит и запрос html документа без реферера, и прямой запрос мувика.. Как вычислить этот запрос и стоит ли заморачиватся?
Я почему ищу кого-то, кто юзает защиту - интересно узнать насколько снизился трафик при ее применении и стоит ли вообще заморачиваться..
Как я понимаю спонсорским хостам и мхг это не нужно - ибо скачиваемый мувик имеел лейбл платника, и если понравится дрочеру, он туда придет. Остаются те кто юзает свои сервера для хостинга мувиков, ибо в вышеописанном случае не передается вебмастерский id, что не есть хорошо -)

Актуальная тема!

В догонку вопрос: Есть подозрение, что контент качают ещё и из пиринговых сетей. Тоесть лежит себе файл на сайте, и если к нему правильно известен путь, тогда его вносят в специальный файл для пирингового агента, расшаривают по пиринговой сети, и пиши-пропало.

_http://www.antihotlinking.com/

Для мувиков самое-то

GetCyberCash писал:

_http://www.antihotlinking.com/ Для мувиков самое-то

Кто нить юзал? Отзывы?

JW писал:

Вот этот процент - 16% direct меня и беспокоит. Сюда наверно входит и запрос html документа без реферера, и прямой запрос мувика..

при открытии мувика плеером реферер обычно не передается, так что...

Почесал репу...
Возможно, механизм может быть такой...

1. Галера/фришник/мемберка делается пхп-файлом (можно с .html расширением - RTFM). В нем ставится кука или сессия. Последнее не желательно на большой нагрузке.
2. Делается реврайт мувиков на скрипт в корневом .htaccess:
RewriteEngine On
RewriteRule ^(.+\.avi)$ /getmovie.php?moviepath=$1 [L]
RewriteRule ^(.+\.mpg)$ /getmovie.php?moviepath=$1 [L]
и т.д.
3. Этот скрипт проверяет правильность кукиса/сессии и если правильно, то берет мувик из переданной переменной $_REQUEST['moviepath'] и выплевывает мувик клиенту (только осторожно, через небольшой FIFO-буфер! скажем, 4096 байт. и не читать весь мувик со старта!). Иначе:

header("HTTP/1.1 403 Forbidden");
exit();

Таким образом, не зайдя на пагу не удастся скачать мувик. Правда вот не знаю, передастся ли кукис от броузера к плееру. Надо тестить.