☰

Lighttpd referer 问题

tag-icon • tag-icon lighttpd
Lighttpd referer 问题

我在阻止来自不同域的文件访问方面遇到问题。

我在“虚拟主机”中的 lighty 配置中添加了以下内容：

$HTTP["referer"] !~ "^($|http://www\.my-site\.net)" {
    url.access-deny = ( "" )
}

但无论如何该网站都www.example.com可以访问http://player.my-site.net/player.swf，并且无需引荐来源即可直接访问。

任何想法？

//编辑

这是我的旧 apache .htaccess，它带有一个运行完美的重写规则，但我不知道如何将其转换为 lighty：

RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_REFERER} !^http://my-site\.net/ [NC]
RewriteCond %{HTTP_REFERER} !^http://www\.my-site\.net/ [NC]
RewriteCond %{HTTP_REFERER} !^http://player\.my-site\.net/ [NC]
RewriteCond %{HTTP_REFERER} !^http://stream\.my-site\.net/ [NC]
RewriteRule .* - [L,R=404]

答案1

我认为您误解了浏览器在存在热链接资源时的行为。请考虑以下两种情况：

  1. 用户加载了 example.com，该网站已链接到 my-site.net 上的 Flash 资源。用户的浏览器发出两个单独的请求 - 一个请求到 example.com 以检索页面，另一个请求到 my-site.net 以检索热链接的资源。

  2. 用户加载 my-site.net，它已链接到 my-site.net 上的 Flash 资源。用户的浏览器发出两个单独的请求 - 一个请求到 my-site.net 以检索页面，另一个请求到 my-site.net 以检索热链接的资源。

从 my-site.net 的角度来看，场景 1 中的第二个请求可能与场景 2 中的请求相同。它们都来自用户的浏览器，并且都请求相同的资源。浏览器通常会发送 Referer 标头，但绝对不是必须这样做。基于 Referer 标头的热链接预防虽然通常有效，但并非万无一失。

如果热链接预防对您来说真的非常重要，您应该考虑基于脚本的解决方案——在您最喜欢的搜索引擎上搜索“热链接预防”，我保证您会找到一大堆。

相关内容