- 我想允許從幾個不同的機器人在我的網站上抓取影像并排除所有其他機器人。
- 我想允許至少一個檔案夾中的影像不被任何請求阻止。
- 我不想在我自己的網站上阻止訪問者的影像請求。
- 我不想在 .htaccess 檔案中包含我的域名以實作可移植性。
我在這里問這個問題而不是自己簡單地測驗以下代碼的原因是我自己作業，沒有可以詢問的大學或可以測驗的外部資源。我認為我得到的是正確的，但我發現 .htaccess 規則非常混亂，我不知道我現在什至不知道什么。
RewriteCond %{HTTP_REFERER} !^$ [OR]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?bing\.. $ [NC,OR]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?facebook\.. $ [NC,OR]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?google\.. $ [NC,OR]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?instagram\.. $ [NC,OR]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?linkedin\.. $ [NC,OR]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?reddit\.. $ [NC,OR]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?twitter\.. $ [NC,OR]
RewriteCond %{REQUEST_URI} !^/cross-origin-resources/ [NC,OR]
RewriteCond %{HTTP_HOST}@@%{HTTP_REFERER} !^([^@]*)@@https?://\1/.* [NC]
RewriteRule \.(bmp|gif|jpe?g|png|webp)$ - [F,L,NC]
我已經在htaccess tester上對其進行了測驗，看起來不錯，但在使用以下 URL 進行測驗時確實抱怨最后一行：http : //www.example.co.uk/poignant/foo.webp
uj5u.com熱心網友回復：
你有相反的邏輯。正如所寫，這些條件（RewriteCond指令）將始終成功，并且請求將始終被阻止。
您有一系列進行 OR 運算的否定條件。如果所有條件都匹配，這些只會失敗（即不阻止請求），這是不可能的。（例如。Referer標題不能是bing 和 facebook。）
您需要洗掉OR所有RewriteCond指令上的標志，因此它們是隱式AND'd。
順便說一句，@StephenOstermiller 的評論中建議將HTTP_REFERER支票合并為一個（這是一個很好的），這相當于擁有單獨的條件AND'd，而不是OR'd （正如您最初發布的那樣）。
- 我想允許從幾個不同的機器人在我的網站上抓取影像并排除所有其他機器人。
OR如上所述更正/AND 后，此規則可能會允許所有機器人抓取您的網站影像，因為機器人通常不會發送Referer標頭。這些指令并不是真正關于“抓取”，它們允許某些網站在其域中顯示您的影像（即盜鏈）。這可能是意圖，但是，這不是您在第 1 點中所說的內容。
（要阻止機器人抓取您的網站，您需要檢查User-Agent請求標頭，即HTTP_USER_AGENT- 這在單獨的規則中可能會更好。）
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?bing\.. $
小點，但 $正則運算式的末尾是多余的。Referer當您只對hostname感興趣時，無需匹配整個。盡管這些站點可能有一個Referrer-Policy集，以防止在Referer標題中（由瀏覽器）發送 URL 路徑，但這仍然是不必要的。
RewriteCond %{HTTP_HOST}@@%{HTTP_REFERER} !^([^@]*)@@https?://\1/.* [NC]
在評論中，您問的是這條線的作用。這滿足您串列中的第 3 點和第 4 點，因此肯定需要它。它確保所請求的Host標題（HTTP_HOST）的匹配的主機名中Referer。所以請求來自同一個站點。
另一種方法是在您試圖避免的條件下對您的域進行硬編碼。
（同樣，.*正則運算式的尾隨是不必要的，應該洗掉。）
這是通過\1在正則運算式中使用內部反向參考HTTP_REFERER與TestString（第一個引數）中的匹配項HTTP_HOST來實作的。該字串只是一個不會出現在或服務器變數中的任意字串。@@HTTP_HOSTHTTP_REFERER
如果您展開TestString以查看匹配的內容，這會更清楚。例如，如果您https://example.com/myimage.jpg從主頁（即https://example.com/）發出內部請求，則指令中的TestStringRewriteCond是：
example.com@@https://example.com/
然后將其與正則運算式匹配^([^@]*)@@https?://\1/（CondPattern!上的前綴是一個運算子并且是引數的一部分，而不是正則運算式）。
([^@]*)- 第一個捕獲組捕獲example.com（ 的值HTTP_HOST）。@@https?://- 簡單地@@https://在TestString 中匹配（ 的一部分HTTP_REFERER）。\1- this is an internal backreference. So this must match the value captured from the first capturing group (#1 above). In this example, it must matchexample.com. And it does, so there is a successful match.- The
!prefix on the CondPattern (not strictly part of the regex), negates the whole expression, so the condition is successful when the regex does not match.
So, in the above example, the regex matches and so the condition fails (because it's negated), so the rule is not triggered and the request is not blocked.
However, if a request is made to https://example.com/myimage.jpg from an external site, eg. https://external-site.example/ then the TestString in the RewriteCond directive is:
example.com@@https://external-site.example/
Following the steps above, the regex fails to match (because external-site.example does not match example.com). The negated condition is therefore successful and the rule is triggered, so the request is blocked. (Unless one of the other conditions failed.)
Note that with the condition as written, www.example.com is different to example.com. For example, if you were on example.com and you used an absolute URL to your image using www.example.com then the regex will fail to match and the request will be blocked. This could perhaps be incorporated into the regex, to allow for this. But this is very much an edge case and can be avoided with a canonical 301 redirect earlier in the config.
RewriteCond %{HTTP_REFERER} !^$
This allows an empty (or not present) Referer header. You "probably" do need this. It allows bots to crawl your images. It permits direct requests to images. It also allows users who have chosen to suppress the Referer header to be able to view your images on your site.
HOWEVER, it's also possible these days for a site to set a Referrer-Policy that completely suppresses the Referer header being sent (by the browser) and so bypasses your hotlink protection.
RewriteRule \.(bmp|gif|jpe?g|png|webp)$ - [F,L,NC]
Minor point, but the L flag is not required when the F flag is used (it is implied).
Are you really serving .bmp images?!
Aside: Sites don't necessarily "hotlink"
Some of these external sites (bing, Facebook, Google, Instagram, LinkedIn, Reddit, twitter, etc.) don't necessarily "hotlink" images anyway. They often make their own (resized/compressed) "copy" of the image instead (a bot makes the initial request to retrieve the image - with no Referer - so the request is not blocked).
So, explicitly permitting some of these sites in your "hotlink-protection" script might not be necessary anyway.
Summary
Taking the above points into consideration, the directives should look more like this:
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?(bing|facebook|google|instagram|linkedin|reddit|twitter)\.
RewriteCond %{REQUEST_URI} !^/cross-origin-resources/ [NC]
RewriteCond %{HTTP_HOST}@@%{HTTP_REFERER} !^([^@]*)@@https?://\1/
RewriteRule \.(gif|jpe?g|png|webp|bmp)$ - [F,NC]
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/353079.html
上一篇：用.htaccess重寫檔案夾