Я разместил статическую веб-страницу на страницах Gitlab. URL-адрес веб-страницы: myname.gitlab.io
У меня есть другой веб-сайт, размещенный на hostgator
, который имеет URL-адрес "mysecondwebsite.com"
. "mysecondwebsite.com"
имеет тысячи статических html-страниц, размещенных на различных путях, таких как "mysecondwebsite.com/charts/folder1/1.html"
, "mysecondwebsite.com/charts/folder1/2.html"
, "mysecondwebsite.com/charts/folder1/3.html"
и так далее.
Я не хочу, чтобы "mysecondwebsite.com"
был доступен напрямую, как и страницы в нем. Следовательно, я включил защиту от хотлинков, которая работает, как и ожидалось. Теперь я также хочу разрешить доступ к "mysecondwebsite.com"
ТОЛЬКО ОТmyname.gitlab.io
. На этом веб-сайте есть список гиперссылок, при нажатии на которые открывается соответствующая страница в "mysecondwebsite.com"
. Для этого я ввел следующее в файл .htaccess
на hostgator, что не помогает. Я вижу 403 запрещено
# IP to allow
order allow,deny
deny from all
allow from gitlab.io
Текущие настройки защиты хотлинка -
# DO NOT REMOVE THIS LINE AND THE LINES BELOW HOTLINKID:r2xGl7fjrh
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?mysecondwebsite.com/.*$ [NC]
RewriteRule .*\.(.*|jpg|jpeg|gif|png|bmp|tiff|avi|mpeg|mpg|wma|mov|zip|rar|exe|mp3|pdf|swf|psd|txt|html|htm|php)$ https://mysecondwebsite.com [R,NC]
# DO NOT REMOVE THIS LINE AND THE LINES ABOVE r2xGl7fjrh:HOTLINKID
Я никоим образом не являюсь экспертом в области веб-хостинга. Пожалуйста, могу ли я получить некоторую помощь, чтобы заставить это работать.
ОБНОВЛЕНО
Options All -Indexes
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http(s)?://((myfirstwebsite\.com)|((www\.)?mysecondwebsite\.com))/ [NC]
RewriteRule .* - [F]
ДАМП ЗАГОЛОВКА HTTP LIVE
https://mysecondwebsite.com/charts/thisfolder/thisfile.html
Host: mysecondwebsite.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Alt-Used: mysecondwebsite.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
GET: HTTP/2.0 403 Forbidden
cache-control: private, no-cache, no-store, must-revalidate, max-age=0
pragma: no-cache
content-type: text/html
content-length: 699
date: Wed, 06 Apr 2022 07:13:17 GMT
server: LiteSpeed
content-security-policy: upgrade-insecure-requests
alt-svc: h3 = ":443"; ma=2592000, h3-29 = ":443"; ma=2592000, h3-Q050 = ":443"; ma=2592000, h3-Q046 = ":443"; ma=2592000, h3-Q043 = ":443"; ma=2592000, quic = ":443"; ma=2592000; v = "43,46"
X-Firefox-Spdy: h2
---------------------
https://mysecondwebsite.com/favicon.ico
Host: mysecondwebsite.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0
Accept: image/avif,image/webp,*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Alt-Used: mysecondwebsite.com
Connection: keep-alive
Referer: https://mysecondwebsite.com/charts/thisfolder/thisfile.html
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
GET: HTTP/3.0 404 Not Found
content-type: text/html
last-modified: Mon, 28 Mar 2022 13:48:20 GMT
etag: "999-6241bca4-dfd29bee5117e228;br"
accept-ranges: bytes
content-encoding: br
vary: Accept-Encoding
content-length: 911
date: Mon, 04 Apr 2022 10:11:14 GMT
server: LiteSpeed
content-security-policy: upgrade-insecure-requests
alt-svc: h3 = ":443"; ma=2592000, h3-29 = ":443"; ma=2592000, h3-Q050 = ":443"; ma=2592000, h3-Q046 = ":443"; ma=2592000, h3-Q043 = ":443"; ma=2592000, quic = ":443"; ma=2592000; v = "43,46"
X-Firefox-Http3: h3
---------------------
Спасибо, мистер Уайт. Я обновил настройки горячей ссылки в вопросе
Итак, я отключил защиту от горячих ссылок для html, а также переместил форму разрешения и запрета блокировки htaccess. Я понимаю, что запрос сделан из браузера, который может быть из любой точки земного шара. Итак, запрос исходит не от gitlab.io
В этом случае есть ли способ добиться того, что мне нужно?
Практически только путем проверки реферера, что, как известно, ненадежно.
Да, изменив фактический скрипт защиты хотлинка (чтобы сделать исключение для хоста myname.gitlab.io
в заголовке Referer
), но то, что вы разместили выше, — это просто графический интерфейс вашей панели управления хостингом. Разве это не генерирует какие-то директивы .htaccess
или что-то в этом роде?
да, он создает код htaccess. Я обновил вопрос с ним
allow from gitlab.io
не работает с заголовком реферера http, как вы ожидаете. Скорее он работает на основе IP-адреса пользователя, делающего запрос.
Вместо этого вы хотите использовать что-то, что проверяет реферер и отказывает в доступе, когда он не содержит myname.gitlab.io
или имя хоста вашего собственного веб-сайта. Вы можете сделать это с помощью mod_rewrite
, поместив в свой файл .htaccess
следующее:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http(s)?://((myname\.gitlab\.io)|((www\.)?mysecondwebsite\.com))/ [NC]
RewriteRule .* - [F]
Это позволит реферерам с вашего сайта gitlab, а затем позволит этим страницам получать дополнительные ресурсы, такие как изображения, js и css. В этом правиле:
RewriteEngine on
- включает перезапись, это нужно указать один раз в вашем .htaccess
и использовать во всех правилах и условиях перезаписи.RewriteCond
- указывает условие для следующего правила перезаписи!
говорит, что следующее регулярное выражение должно быть инвертировано (не сопоставлено)^
— начало регулярного выраженияNC
означает «без регистра», что означает, что это правило нечувствительно к регистру и будет работать как для ввода в верхнем, так и в нижнем регистре.RewriteRule
это фактическое правило.*
говорит, что он соответствует всем URL-адресам (в данном случае имеет значение указанное выше условие)-
означает отсутствие целевого URLF
говорит, что он должен отображать статус «запрещено», а не перенаправлять или внутренне изменять URL-адрес.Проблема с этим подходом заключается в том, что он будет запрещать некоторые запросы, которые на самом деле относятся к gitlab. Не все браузеры фактически отправляют заголовок реферера при любых обстоятельствах.
Большое спасибо. Я обновил вопрос с помощью существующего правила перезаписи, созданного для условий горячей ссылки. Подскажите, пожалуйста, куда это добавить в файле или, может быть, добавить свои правила к уже сгенерированному?
Я бы заменил сгенерированное правило и отключил защиту от хотлинка. Защита от хотлинка делает противоположный того, что вы хотите. Это Только разрешает запросы к вашим файлам с вашего сайта и нет с других сайтов.
Я обновил вопрос о том, как выглядит файл htaccess. Это все еще не работает ... Страницы, содержащие различный набор гиперссылок, указывающих на «mysecondwebsite.com», имеют URL-адрес формы - somename.gitlab.io/charts/folderxxx, somename.gitlab.io/charts/folderyyy и так далее. Должен ли я добавить что-то более конкретное? Я все еще вижу запрещенную ошибку 403 :(
Это заблокирует все статические ресурсы на странице (поскольку Referer
для них является сам веб-сайт). Лично я думаю, что просто оставил бы существующий сценарий защиты от хотлинков (сгенерированный графическим интерфейсом) и включил отдельное правило/исключение перед этим для <name>.gitlab.io
, которое предотвращает запуск защиты от хотлинков для этого домена. (При условии, что в файле .htaccess
нет других директив.)
Спасибо, мистер Уайт. Пожалуйста, не могли бы вы поделиться сценарием правила исключения, о котором вы думаете? Я оставлю исходный сценарий хотлинка и добавлю правило, которое вы предложите и протестируете.
Спасибо, Стивен и мистер Уайт. Сейчас у меня включены горячие ссылки, а также условие перезаписи от Стивена. Все работает так, как ожидалось. Стивен. Не могли бы вы пояснить причину включения gitlab.io и mysecondwebsite в условие перезаписи. Я думал, что реферером будет только сайт gitlab.io?
Также, пожалуйста, не могли бы вы прокомментировать, что делает правило перезаписи? (Куда перенаправляет пользователя)
Я добавил больше пояснений о том, что делает правило перезаписи. Я не вдавался в подробности регулярного выражения, но могу сделать и это, если вам нужна эта информация.
Огромное спасибо. Я наблюдаю странное поведение, когда некоторые URL-адреса открывают нужную страницу, в то время как другие по-прежнему показывают 403 запрещенных. Я использую браузер хром
Я отключил всю защиту от хотлинков просто для проверки. Нет разницы.
В этом правиле нет ничего, что заставляло бы его работать для одних URL, но не для других. Возможно, это будет работать для некоторых Запросы, а не для других, но вам нужно будет предоставить мне больше информации, чтобы помочь отладить ее, например, что такое заголовок реферера в этих случаях.
Привет, Стивен. Я не знаю, как это работало вчера. Сегодня вообще не работает. Я разместил трафик заголовка HTTP в вопросе. Кроме того, на данный момент обновлено содержимое файла .htaccess. Пожалуйста, не могли бы вы взглянуть.
Мое правило несовместимо с защитой от горячих ссылок. Вы должны либо удалить защиту от горячих ссылок при использовании моего правила, либо использовать решение mrwhite.
Я удалил хотлинк. К сожалению, пока не повезло :(
Я также ожидаю ошибки 403 для этого запроса, который вы отправили, потому что нет заголовка реферера.
Спасибо. да в значительной степени конец дороги. вздох вздох
Вы можете добавить исключение из правила, чтобы разрешить запросы без реферера, но это будет означать, что ваш сайт доступен, если кто-то посещает его напрямую.
Сегодня рано утром меня поразило, что реферер не проходит, потому что на веб-странице для всех гиперссылок установлен параметр «noopener noreferrer»!! Я избавился от noreferrer, и он работает, как и ожидалось. Большое спасибо за вашу помощь. Я очень ценю это.
Please could you share what the exception rule script is that you're thinking?
Это просто альтернатива отличному ответу @StephenOstermiller...
Вместо этого вы можете оставить без изменений существующий сценарий «защиты от хотлинка», сгенерированный графическим интерфейсом панели управления (и вносить любые изменения через графический интерфейс по мере необходимости). Но включите дополнительное правило до для вашей защиты от хотлинков, чтобы сделать исключение для любых доменов, к которым вам нужно предоставить доступ.
# Abort early if request is coming from an "allowed" domain
RewriteCond %{HTTP_REFERER} ^https://myname\.gitlab\.io($|/)
RewriteRule ^ - [L]
# Normal hotlink-protection follows...
Это предотвращает обработку защиты от хотлинка, когда запрос поступает из разрешенного домена. Так что доступ разрешен.
Это предполагает, что у вас нет других директив, которые должны быть обработаны в соответствии с этим правилом.
Спасибо. Я все еще не работаю. Пожалуйста, обратитесь к моим комментариям в ответе выше.
@ usert4jju7 Если заголовки HTTP, которые вы добавили к вопросу, являются результатом нажатия ссылки на gitlab.io
, то заголовок Referer
не отправляется - это ваша проблема. Это может быть результатом gitlab.io
установки более строгих ограничений Referrer-Policy
— если это так, то, к сожалению, вы не можете это контролировать. (В стороне: Решение @Stephen предназначено для использования вместо вашей существующей защиты от хотлинка, созданной графическим интерфейсом вашей панели управления.)
Спасибо, мистер Уайт. Я удалил все горячие ссылки. Это оставляет меня только с конфигурацией Стивена. До сих пор не работает. Пробовал разные браузеры. Не повезло еще
Вероятно, вам нужно изменить защиту хотлинка. (Значит, ваша защита от хотлинков блокирует URL-адреса страниц, а также активы?) Пожалуйста, отредактируйте свой вопрос, включив в него сценарий «защиты от хотлинков». Эти дополнительные директивы действительно блокируют «пользователя», поскольку запрос (когда пользователь щелкает ссылку) исходит от пользователя, а не от
gitlab.io
. (В любом случае сервер может быть не настроен для разрешения IP-адресов.)