htaccess-Code gegen Hotlinking

[Martin11]

Hallo,
ich möchte demnächst meine Bilder für Sumas und Co. in der robots.txt freigeben, aber ein Hotlinking verhindern.
Google, Bing und Pinterest sollen davon ausgenommen sein.
Ein alternatives Bild mit einem schlauen Hinweis soll nicht angezeigt werden.

Bei meinen Recherchen habe ich etwas unterschiedliche Codes gefunden.
Vielleicht kann mir jemand sagen, ob das alles gleich gut funktioniert oder evtl. doch Unterschiede existieren.

Hier mal ein Beispiel, bei dem mir in etwa klar ist, was welche Zeile macht:

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourwebsite.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?facebook.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?twitter.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?other-websites-go-here.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [F]

a)Die 2. Zeile, eigene Domain betreffend (die noch einzusetzen ist)
Hier habe ich folgende Alternativen gefunden, bei denen die eine sich nur im https unterscheidet, die tradino-Zeile aber schon anders aussieht.

RewriteCond %{HTTP_REFERER} !^https://(www\.)?tradino-shop\.de(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https://(www\.)?perun.net [NC]

b)Zeile 3-5, Sumas+Pinterest betreffend
Hier habe ich drei etwas andere Zeilen gefunden. Zwei unterschiedliche Versionen für Google und die Pinterest-Zeile hat vorne kein www, aber hinten ein "com" mit nur einem Punkt danach.

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC]
RewriteCond %{HTTP_REFERER} !^https://www\.google\..*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://pinterest\.com.*$ [NC]

c) Wo in htaccess einfügen?
In meiner htaccess steht schon einiges drin (301-redirect, Browser-Caching, deflate-Komprimierung, PW-Schutz).
Wo füge ich den Code ein, am besten ganz unten?


Danke!

Martin11

[Nils Dornblut]

c) Wo in htaccess einfügen?
In meiner htaccess steht schon einiges drin (301-redirect, Browser-Caching, deflate-Komprimierung, PW-Schutz).
Wo füge ich den Code ein, am besten ganz unten?

Das ist oft egal, aber grundsätzlich sollten Sie sich überlegen wann Sie die Ausführung wollen und was davor noch passieren soll.

Was von den anderen drei Varianten jetzt die beste Variante ist, kann ich nicht genau sagen. Hier hat vielleicht Enigma oder andere noch Tipps.

Mit freundlichen Grüßen


Nils Dornblut

[Enigma]

Hier mal ein Beispiel, bei dem mir in etwa klar ist, was welche Zeile macht:

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?yourwebsite.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?facebook.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?twitter.com [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?other-websites-go-here.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [F]

a)Die 2. Zeile, eigene Domain betreffend (die noch einzusetzen ist)
Hier habe ich folgende Alternativen gefunden, bei denen die eine sich nur im https unterscheidet, die tradino-Zeile aber schon anders aussieht.

RewriteCond %{HTTP_REFERER} !^https://(www\.)?tradino-shop\.de(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https://(www\.)?perun.net [NC]

b)Zeile 3-5, Sumas+Pinterest betreffend
Hier habe ich drei etwas andere Zeilen gefunden. Zwei unterschiedliche Versionen für Google und die Pinterest-Zeile hat vorne kein www, aber hinten ein "com" mit nur einem Punkt danach.

RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?google.com [NC]
RewriteCond %{HTTP_REFERER} !^https://www\.google\..*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://pinterest\.com.*$ [NC]

Im ersten Codebeispiel wurden zwar die Punkte nach "www" mit einem Backslash "entwertet", nicht aber die vor den Domainendungen. Stringenter ist es, das dort auch zu tun, da ein Punkt in einer RegEx für ein beliebiges Zeichen steht, \. aber ausschließlich für einen Punkt.

Auch ich würde vorsichtshalber HTTP und HTTPS zulassen. Die Klammern um das s sind aber überflüssig.

Die Zeichen (/.*)?$ beim zweiten Codebeispiel machen es ebenfalls etwas stringenter. Beim ersten Beispiel müssen die URLs nur wie angegeben beginnen. Es gibt aber z. B. auch Top-Level-Domains wie .com.tw - diese würden dann ebenfalls ausgenommen. Möchte man dies nicht, kann man die angegebenen Zeichen dahinter setzen. Das bedeutet, dass entweder nichts folgt oder ein Slash oder ein Slash plus weitere Zeichen. Es verhindert aber, dass weitere Zeichen folgen, die nicht von einem Slash abgetrennt werden.

Im dritten Codebeispiel wird dem Umstand Rechnung getragen, dass Google etc. unter diversen Top-Level-Domains erreichbar sind (.de, .fr, .com etc.).

Ich persönlich könnte mir das so vorstellen:

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?yourwebsite\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?google\.[^/]+(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?facebook\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?twitter\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?other-websites-go-here\.com(/.*)?$ [NC]
RewriteRule \.(jpe?g|png|gif|svg)$ - [F]

Bei Google ist die Top-Level-Domain wie gesagt variabel, daher habe ich dafür [^/]+ eingesetzt - mindestens ein Zeichen, das kein Slash ist; eine beliebige Anzahl solcher Zeichen ist möglich.

Diese Variante ist ziemlich stringent (bei regulären Ausdrücken immer empfehlenswert, da man leicht sehr viel mehr erwischt als man möchte), aber auch variabel genug, um Sonderfälle abzudecken.

.jpg und .jpeg habe ich zusammengefasst und dafür auch .svg hinzugefügt.

c) Wo in htaccess einfügen?
In meiner htaccess steht schon einiges drin (301-redirect, Browser-Caching, deflate-Komprimierung, PW-Schutz).
Wo füge ich den Code ein, am besten ganz unten?

Ich persönlich setze Passwortschutz nach ganz oben, darunter Weiterleitungen (HTTP -> HTTPS, domain.tld -> www.domain.tld oder umgekehrt etc.), dann käme die hier besprochene Passage. Caching und Komprimierung setze ich nach unten.

Gruß
Jan

[Martin11]

Vielen Dank, sehr "stringent"

Ich habe gestern noch zwei weitere Varianten gefunden, aber die spare ich mir jetzt. Erstaunlich, dass es so viele Wege zum gleichen Ziel gibt.

http/https:
Das hatte ich schon vermutet, also dass der eine Code beide Varianten abdeckt und dass das im Zweifelsfall empfehlenswert ist. Sehen tut man diese flexiblere Variante aber seltsamerweise immer nur mit der Klammer-Schreibweise.

Variable TLD bei Google:
Gute Idee!
Speziell für die vom Code anvisierte Bildersuche von Google dürfte zwar "com" reichen, aber wer weiß, was denen noch alles einfällt mit Bildern, die in den SERPs verwendet werden (rich snippets) oder wenn Google technisch etwas ändert. Je flexibler, desto besser.

Pinterest:
Die Pinterest-Zeile sieht in meinem gefundenen Beispiel anders aus, nämlich

 
 RewriteCond %{HTTP_REFERER} !^https://pinterest\.com.*$ [NC]

Sollte das nicht genauso aussehen oder was soll da anders sein bei Pinterest, hat das auch mit der TLD zu tun?

Reihenfolge:
Bisher sieht das bei mir so aus:
1. Verbote, z.B. Zugriff auf wp-config
2. PW-Schutz
3. 301-Redirect, .html --> ohne .html
4. Wordpress-Standard-Code mit RewriteEngine On:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
5. Caching und Komprimierung

Du würdest das Hotlinking-Verbot nach dem 301-redirect platzieren?

[Enigma]

http/https:
Das hatte ich schon vermutet, also dass der eine Code beide Varianten abdeckt und dass das im Zweifelsfall empfehlenswert ist. Sehen tut man diese flexiblere Variante aber seltsamerweise immer nur mit der Klammer-Schreibweise.

Ist für RegEx-Einsteiger vielleicht etwas deutlicher. Wird keine Klammer gesetzt, gilt der Quantor (hier das Fragezeichen, dazu gehören aber auch +, * etc.) für das davorstehende Zeichen. In der Bedeutung ist es also in diesem Fall äquivalent.

Pinterest:
Die Pinterest-Zeile sieht in meinem gefundenen Beispiel anders aus, nämlich

RewriteCond %{HTTP_REFERER} !^https://pinterest\.com.*$ [NC]

Sollte das nicht genauso aussehen oder was soll da anders sein bei Pinterest, hat das auch mit der TLD zu tun?

Ist ja ein anderes Codebeispiel. Ich würde diese Zeile genauso bilden wie die anderen im von mir vorgeschlagenen Code.

Reihenfolge:
Bisher sieht das bei mir so aus:
1. Verbote, z.B. Zugriff auf wp-config
2. PW-Schutz
3. 301-Redirect, .html --> ohne .html
4. Wordpress-Standard-Code mit RewriteEngine On:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
5. Caching und Komprimierung

Du würdest das Hotlinking-Verbot nach dem 301-redirect platzieren?

Kommt auf den genauen Code an - ein "RewriteEngine On" muss über diesen Zeilen stehen. In Deiner Reihenfolge würde ich es zwischen Punkt 4 und Punkt 5 einsortieren, möglichst noch vor dem schließenden </IfModule> von Punkt 4.

Gruß
Jan

[Martin11]

Also würde der fertige Code so aussehen, mit der Pinterest-Zeile so wie Twitter und FB, Xing habe ich auch noch ergänzt:

RewriteCond %{HTTP_REFERER} !^$  
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?meinedomain\.com(/.*)?$ [NC]  
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?google\.[^/]+(/.*)?$ [NC]  
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?facebook\.com(/.*)?$ [NC]  
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?twitter\.com(/.*)?$ [NC]  
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?pinterest\.com(/.*)?$ [NC]  
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?xing\.com(/.*)?$ [NC]  
RewriteRule \.(jpe?g|png|gif|svg)$ - [F]

Und an den Standard-Code von Wordpress angehängt, mit einer Leerzeile und Kommentarzeile dazwischen (ist das o.k.?):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

#Hotlinking unterbinden
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?meinedomain\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?google\.[^/]+(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?facebook\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?twitter\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?pinterest\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?xing\.com(/.*)?$ [NC]
RewriteRule \.(jpe?g|png|gif|svg)$ - [F]

</IfModule>

[Enigma]

Jepp, so sieht's für mich gut aus.

Ich würde noch ein paar der größeren Suchmaschinen hinzufügen.

Gruß
Jan

[Martin11]

Zumindest Bing würde sich wohl noch lohnen. Die Codezeile für Bing dann analog zur Google-Zeile mit flexibler TLD?

Dass der Hotlinking-Code mit Leer- und Kommentarzeile jetzt so in den WP-Standardcode "reingeflätscht" ist, stört selbigen sicher nicht, weil doch vom eigentlichen Code getrennt?

[Enigma]

Zumindest Bing würde sich wohl noch lohnen. Die Codezeile für Bing dann analog zur Google-Zeile mit flexibler TLD?

Bing besitzt zwar bing.de, bing.fr, bing.co.uk und so weiter und so fort, leitet aber immer zu bing.com weiter. Es schadet nicht, wenn Du die flexible Variante wählst, wird aber voraussichtlich auch keine Vorteile bringen.

Eine ganz gute und leidlich aktuelle Übersicht über den Suchmaschinenmarkt bietet https://seo-summary.de/suchmaschinen/.

Dass der Hotlinking-Code mit Leer- und Kommentarzeile jetzt so in den WP-Standardcode "reingeflätscht" ist, stört selbigen sicher nicht, weil doch vom eigentlichen Code getrennt?

Du nutzt lediglich die Überprüfung auf das Vorhandensein des mod_rewrite-Moduls mit, ansonsten gibt es da keine Verzahnung. Wenn es Dir lieber ist, kannst Du auch einen separaten IfModule-Block aufmachen. Bei DF ist auch dieser nicht unbedingt nötig, da mod_rewrite immer aktiviert ist, aber es dient der besseren Portabilität.

Andererseits erhält man einen Fehler 500, wenn man ein nicht installiertes Apache-Modul zu nutzen versucht, was auch ein ganz guter Hinweis sein kann, warum etwas nicht funktioniert. Ich habe z. B. vor einiger Zeit in einem IfModule-Block auf Existenz von mod_header geprüft, und mein Konstrukt funktionierte ohne Fehlermeldung einfach nicht wie gewünscht. Es hat eine Weile gedauert, bis ich gesehen habe, dass das s am Ende des Modulnamens fehlt... Somit war das abgefragte Modul nicht vorhanden und alles im IfModule-Block wurde einfach nicht ausgeführt, ganz so, wie es in Deinem Fall bei fehlendem mod_rewrite-Modul wäre.

Wie auch immer, Du kannst den neuen Code also auch einfach unter den WordPress-Code setzen, aber es macht letztlich keinen Unterschied - soweit ich weiß, passt WordPress den .htaccess-Code nicht nachträglich an (nur dafür könnte es wichtig sein, den Block unverändert zu lassen).

Gruß
Jan

[Martin11]

Wie auch immer, Du kannst den neuen Code also auch einfach unter den WordPress-Code setzen, aber es macht letztlich keinen Unterschied - soweit ich weiß, passt WordPress den .htaccess-Code nicht nachträglich an (nur dafür könnte es wichtig sein, den Block unverändert zu lassen).

Ich glaube, deswegen hatte ich so ein komisches Gefühl, also weil ich irgendwann mal gelesen habe, dass das bei WP schon so ist und ich es noch dumpf im Hinterkopf hatte. Habe dann auf die Schnelle das hier gefunden:
https://wordpress.org/support/topic/...ult-by-itself/

Und auch bei https://perishablepress.com/stop-wordpress-htaccess/ steht

The big moral of the story here is that you need to add any custom .htaccess rules outside of the BEGIN and END markers. Otherwise WordPress will overwrite them with the default permalink rules.
So given the previous points, if you have:

• Custom permalink rules inside of the BEGIN and END markers, WordPress will remove them
• Custom permalink rules outside of the markers (e.g., not using any markers), then WP will add another set of rewrite rules at the end of the .htaccess file

Also wenn ich das richtig verstehe, muss es
a) ein eigener Block unter dem Standard-Code von WP sein und
b) dieser extra Block muss genau wie der WP-Block BEGIN- und END-Marker haben

Analog zum obigen Link vom WP-Forum würde das dann so aussehen, unterhalb des WP-Codes:

 #BEGIN Hotlinking unterbinden
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?meinedomain\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?google\.[^/]+(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?bing\.[^/]+(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?facebook\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?twitter\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?pinterest\.com(/.*)?$ [NC]
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?xing\.com(/.*)?$ [NC]
RewriteRule \.(jpe?g|png|gif|svg)$ - [F]
</IfModule>
# END Hotlinking unterbinden

So müsste dann alles passen.
Das nochmalige RewriteEngine On könnte ich mir wohl sparen, aber wenn es nicht stört, lasse ich es drin.
Wenn schon ein komplett eigener Block, dann soll es auch das für sich selbst haben. Wird auf jeden Fall immer und überall funktionieren.

[Enigma]

Also wenn ich das richtig verstehe, muss es
a) ein eigener Block unter dem Standard-Code von WP sein und
b) dieser extra Block muss genau wie der WP-Block BEGIN- und END-Marker haben

Ich vermute mal, das kommt selten vor, denn ich habe im alten Forum aus Bequemlichkeit sicherlich so einige Male empfohlen, Dinge in diesen Block zu schreiben, und es hat sich nie jemand beschwert...

Aber klar, wenn die Gefahr grundsätzlich besteht, sollte man eigene Regeln außerhalb dieses Blocks anlegen. Deine Schlussfolgerung b) kann ich allerdings nicht herauslesen. Schaden sollte es aber auch nicht, wenn die Kommentarzeilen nicht identisch mit denen des WordPress-Blocks sind.

So müsste dann alles passen.

Sehe ich auch so.

Das nochmalige RewriteEngine On könnte ich mir wohl sparen, aber wenn es nicht stört, lasse ich es drin.
Wenn schon ein komplett eigener Block, dann soll es auch das für sich selbst haben. Wird auf jeden Fall immer und überall funktionieren.

"RewriteEngine On" wird nur einmal benötigt, tut aber auch nichts Schlimmes, wenn es erneut aufgerufen wird. Als wiederverwendbarer Block ist die vollständige Variante sicherlich nicht verkehrt.

Gruß
Jan

[Martin11]

Deine Schlussfolgerung b) kann ich allerdings nicht herauslesen. Schaden sollte es aber auch nicht, wenn die Kommentarzeilen nicht identisch mit denen des WordPress-Blocks sind.

Wahrscheinlich nicht, zumal ja eh nur die Wörter "BEGIN" und "END" identisch sind, der eigentliche Kommentar daneben ist bereits anders als beim WP-Block.
Ich habe mich einfach nur an dem Forumsbeitrag vom ersten Link oben orientiert. Dort hat der Fragende für sein Anliegen (Redirect) folgendes verwendet, was i.O. sein soll:

 #BEGIN HTTPS Redirect
<IfModule mod_rewrite.c>
...
# END HTTPS Redirect

Danke.

[Martin11]

Jetzt ist mir noch etwas eingefallen.
Spricht etwas dagegen, die Rewrite-Zeile mit anderen Medien, die keine Bilder sind, zu ergänzen, z.B. .pdf und .mp3?
Also dann so:

  RewriteRule \.(jpe?g|png|gif|svg|pdf|mp3)$ - [F]

[Enigma]

Spricht etwas dagegen, die Rewrite-Zeile mit anderen Medien, die keine Bilder sind, zu ergänzen, z.B. .pdf und .mp3?

Kurz: Nein.

Gruß
Jan

[Martin11]