Защита Hotlink - Обсуждение - PullRequest
Новая
       4

Защита Hotlink - Обсуждение

0 голосов
/ 01 апреля 2020

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

Это один из кодов, который Кажется, что большинство статей используют: 

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?example.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?example.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?example.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?example.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ http://example.com/nohotlinking.jpg [NC,R,L

1) Однако некоторые статьи имели RewriteCond %{HTTP_REFERER} !^$, а некоторые - нет. Не могли бы вы объяснить, что именно делает эта строка, и лучше ли ее иметь или нет?

2) Кроме того, в отношении последней строки кода я заметил два разных подхода: один

RewriteRule \.(jpg|jpeg|png|gif)$ http://example.com/nohotlinking.jpg [NC,R,L]

и другие

RewriteRule .*\.(jpg|jpeg|png|gif)$ http://example.com/nohotlinking.jpg [NC,R,L]

в чем будет разница, если я добавлю ". *" И еще раз, какой из них вы бы порекомендовали использовать.

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

4) И наконец, может ли этот метод создать какие-либо проблемы при публикации статьи на платформах социальных сетей или для общей производительности SEO сайта?

Заранее большое спасибо!

С уважением, Джордж

1 Ответ

1 голос
/ 01 апреля 2020

1) Однако некоторые статьи содержали RewriteCond% {HTTP_REFERER}! ^ $, А некоторые - нет. Не могли бы вы объяснить, что именно делает эта строка, и лучше ли ее иметь или нет?

Если вы уже немного разбирались в этом, то, возможно, вы уже наткнулись на информацию о том, что реферер это довольно ненадежно.

Это может быть «фальсифицировано» или полностью заблокировано - например, некоторые расширения конфиденциальности браузера или персональные брандмауэры делают это.

Условие !^$ соответствует, если ссылающийся не пусто. Таким образом, в сочетании с остальными, доступ все равно будет разрешен, если клиент отправит пустой реферер, соответственно. этот заголовок запроса не установлен вообще. Если он отправляет реферера из домена, отличного от того, который вы явно разрешаете, или реферер вместо этого будет содержать что-то вроде Blocked by Extension XYZ for Privacy Reasons, то доступ все равно будет заблокирован.

2) Кроме того, в отношении к последней строке кода я заметил два разных подхода: один 

RewriteRule \.(jpg|jpeg|png|gif)$ http://example.com/nohotlinking.jpg [NC,R,L]

и другой 

RewriteRule .*\.(jpg|jpeg|png|gif)$ http://example.com/nohotlinking.jpg [NC,R,L]

в чем будет разница, если я добавлю ". *" и еще раз, какой вы бы порекомендовали использовать.

Поскольку оба шаблона привязаны только в конце, они допускают любые произвольные символы до их.

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

Таким образом, здесь различие довольно «философское» по своей природе, конечный эффект почти такой же.

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

Вы можете получить как общий c с вашим шаблоном регулярных выражений там, как вы хотите. RewriteRule .* https://… чтобы соответствовать абсолютно чему угодно, например.

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

4) Наконец, будет ли это Способ создать какие-либо проблемы при публикации статьи на платформах социальных сетей или для общей производительности SEO сайта?

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

Эти скребки обычно отправляют указанный c конкретный c User-Agent заголовок - так что можно добавить дополнительные исключения, основываясь на этом, при необходимости.

...