Das Putzlowitsch Test- und SEO-Blog
Thema: Tips & Tricks

Direkte Bild-Aufrufe auf Seite weiterleiten – so gehts

Das Problem

In den letzten Tagen ist die Aufregung ob der neuen Google-Bildersuche recht groß und viele versuchen, einen Ausweg aus den sinkenden Besucherzahlen zu finden.

In der neuen Bildersuche werden die Bilder direkt in Original-Auflösung auf der Ergebnisseite geladen. Der Nutzer hat also wenig Anlaß, die Ursprungsseite zu besuchen.

Google-Bildersuche: Links zu Seite/Bilder

Google-Bildersuche: Links zu Seite/Bilder

Immerhin gibt es vier Links (grün), die den Benutzer auf die Ursprungsseite mit dem Bild führen. Dazu kommt ein Link direkt zum Bild [Bild ansehen] und indirekt die Möglichkeit, per Rechtsklick und „Grafik anzeigen“ nur das Bild aufzurufen.

Der direkte Link zum Bild bringt allerdings keine Besucher auf die Seite. Daher gibt es die Idee, den direkten Aufruf eines Bildes aus der Bildersuche auf eine Seite mit dem Bild umzuleiten.

So gehts

Um zu erkennen, ob jemand von der Bildersuche kommt, kann man den Referrer auswerten. Vereinfacht gesagt, könnte man folgende Regel formulieren:

„Ist die Referrer-Domain google.* und die angeforderte Datei ein Bild (jpeg,png,…), dann leite den Nutzer auf eine Seite mit dem Bild um.“

In der .htaccess könnte das so aussehen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond	%{REQUEST_FILENAME} -f
RewriteCond	%{HTTP_REFERER}	^http(s)?://(www\.)?google [NC]
RewriteRule	\.(jpg|png|gif)$	/redirect.php	[L]
</IfModule>

Zunächst wird Rewrite eingeschaltet und die Basis festgelgt.
Dann wird geprüft, ob es die angeforderte Datei überhaupt gibt und ob der Referrer Google ist. Falls ja und die Datei ein Bild ist, wird das PHP-Skript zur Weiterleitung aufgerufen.

So weit, so gut, nur gibt es noch einige Probleme zu lösen.

Leider wird der Referrer auch gesendet, wenn das Bild als Bild auf der Google-Seite geladen wird. Da soll natürlich keine Weiterleitung erfolgen, weil das im Kontext eines Bilder zu einem Fehler führt. Kann man also unterscheiden, ob das Bild geladen wird oder ein Link auf das Bild aufgerufen wird? Ja, mann kann. Zumindest meistens.

Außerdem wird ein bereits geladenes Bild vom Browser im Cache vorgehalten, was zu unvorhergesehenen Ergebnissen bei der Weiterleitung führen kann. Kann man das verhindern? Ja, man kann.

Meine Problemlösungen

Als technische Basis setze ich einen Apache-Server mit den aktiven Modulen mod_rewrite, mod_headers und mod_setenvif voraus. Wobei das Modul mod_setenvif nicht zwingend erforderlich ist, es macht die Sache aber übersichtlicher:

<IFModule mod_headers.c>
Header	set	 Cache-Control "no-cache, no-store, must-revalidate"	env=NO_CACHE
Header	unset	 Expires	env=NO_CACHE
Header	unset	 Last-Modified	env=NO_CACHE
Header	unset	 ETag	env=NO_CACHE
</IfModule>

<IfModule mod_setenvif.c>
SetEnvIf Accept "text/html"	REQ_HTML=1
SetEnvIf Referer "^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/"	DOM_REFERER=$1
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /bilder

RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|gif|png)$	-	[NC,C]

RewriteCond	%{ENV:DOM_REFERER}	google\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.at$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.ch$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.*	-	[E=DO_RDR:1,E=NO_CACHE:1]

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	([^-]+)-([0-9]+)\.(jpg|gif|png)$	/bild-$1-$2.html	[R=302,L]
</IfModule>

Zur Unterscheidung von Bildaufruf (img src=…) und Link verwende ich den Wert von „Accept“ im HTTP-Request-Header. Nach meiner Beobachtung enthält dieses Header-Feld bei Bild-Aufrufen nicht den Typ „text/html“, beim Aufruf von Links, auch zu Bildern, aber schon. Wenn also „text/html“ im Accept-Header zu finden ist, dürfte es sich um den Link zum Bild und nicht um das Laden des Bildes in der Google-Ansicht handeln.

<IfModule mod_setenvif.c>
SetEnvIf Accept "text/html"	REQ_HTML=1
SetEnvIf Referer "^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/"	DOM_REFERER=$1
</IfModule>

Den Accept-Header werte ich in einer SetEnvIf Anweisung aus und setze eine entsprechende Variable, die ich später in den Rewrite-Regeln auswerten kann. Zudem extrahiere ich in dem Block den Domain-Namen aus dem Referer, da ich diesen auch in anderen Rewrite-Regeln benötige.

RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|gif|png)$	-	[NC,C]

Mit den Rewrite-Regeln prüfe ich zunächst die Existenz der Datei und über die Datei-Erweiterung, ob ein Bild aufgerufen wird. Falls nicht, wir der zweite Block der Rewrite-Regeln gar nicht erst ausgeführt.

RewriteCond	%{ENV:DOM_REFERER}	google\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.at$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.ch$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.*	-	[E=DO_RDR:1,E=NO_CACHE:1]

Im zweiten Block wird eine Liste von Referrer-Domains abgearbeitet, für die die Weiterleitung erfolgen soll. In dem Fall sind es die drei Google-Domains, von denen die meisten meiner Besucher kommen (exemple.com ist nur ein Platzhalter). Die Abfrage nach dem Referer kann man natürlich auch anders gestalten. Das hängt halt davon ab, was man damit erreichen will. Hier setze ich mir wieder ein Flag (DO_RDR), das ich später für die Weiterleitung auswerte.

<IFModule mod_headers.c>
Header	set	 Cache-Control "no-cache, no-store, must-revalidate"	env=NO_CACHE
Header	unset	 Expires	env=NO_CACHE
Header	unset	 Last-Modified	env=NO_CACHE
Header	unset	 ETag	env=NO_CACHE
</IfModule>

Außerdem setze ich einen Wert (NO_CACHE), mit dem am Ende geprüft wird, ob das Caching deaktiviert werden soll. Der Block mod_headers steht zwar am Anfang, der Webserver führt diese Anweisungen aber erst ganz zum Schluß aus, kurz bevor die Antwort an den Client gesendet wir. Damit wird das Caching des von Google direkt geladenen Bildes verhinert.

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	([^-]+)-([0-9]+)\.(jpg|gif|png)$	/bild-$1-$2.html	[R=302,L]

Im dritten Rewrite-Block erfolgt dann die Weiterleitung, falls es sich um einen Link-Request (REQ_HTML) handelt und eine Weiterleitung überhaupt ausgeführt werden soll (DO_RDR).

Wohin weiterleiten?

Ein weiteres Problem kann die eigentliche Weiterleitung sein. Wohin soll die Reise gehen?

Im Beispiel ist das relativ einfach. Die Bilder liegen in einem Unterverzeichnis /bilder/ und der Dateinamen besteht aus Bezeichnung und laufender Nummer. Die Zielseiten mit den Bildern bestehen auch aus Bezeichnung und laufender Nummer. Damit läßt sich schon in der .htaccess Datei die Weiterleitungsregel unmittelbar formulieren.

/bilder/tomaten-7.jpg -> /bild-tomaten-7.html
/bilder/banane-23.jpg -> /bild-banane-23.html
...

Schön, wenn man so eine klare Struktur für seine Bilder hat. Ich habe die leider nicht. :-)

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	.*	/rdr.php	[L]

Also muß die Weiterleitung z.B. von einem PHP-Skript erledigt werden, in dem man dann praktisch beliebige Weiterleitunsziele adressieren kann.

In WordPress gibt es für die über die Mediathek hochgeladenen Bilder jeweils eine Attachment-Seite. Nun könnte man sich die Informationen zum Weiterleitungsziel aus der WP-Datenbank holen. Aus Performance-Gründen habe ich da einen etwas anderen Weg gewählt.

Für WordPress, wie z.B. hier bei schnurpsel.de, sieht das rdr.php-Skript so aus:

<?php
define( 'THISPATH', dirname(__FILE__) . '/' );
@include( THISPATH.'redir.php' );

function set_404() {
	header( "HTTP/1.0 404 Not Found", true, 404 );
	echo <<<EOT
<!DOCTYPE html>
<html>
<head><title>404 Not Found</title></head>
<body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
EOT;
	exit;
}

function set_header( $ctype ) {
	@header( "Content-type: $ctype" );
	@header( 'Cache-Control: no-cache' );
	@header( 'Cache-Control: max-age=0', false ); 
	@header( 'Expires:'.gmdate('D, d M Y H:i:s', 0 ).' GMT' );
}

function redirect( $url, $status = 302 ) {
	@header( 'Cache-Control: no-cache, no-store, must-revalidate' );
	@header( "Location: $url", true, $status );
	exit();
}

$img_uri = urldecode( $_SERVER['REQUEST_URI'] );
$redir_url = $redir_b[$img_uri];

if( !$redir_url && @preg_match( '~(.+?)-(1600|1200)\.(jpg|png|gif)$~', $img_uri, $treffer ) ) {
	$redir_url = $redir_b[$treffer[1].'.'.$treffer[3]];
}

if( $redir_url )
	redirect( $redir_url );
else {
	$img_file = THISPATH.$img_uri;
	$img_size = @getimagesize( $img_file );
	if( $img_size ) {
		set_header( $img_size['mime'] );
		@readfile( $img_file );
		exit;
	}
}
set_404();
?>

Download: rdr.zip

In meinem rdr-Skript includiere ich eine weitere PHP-Datei (redir.php), die nur ein Array mit den Weiterleitungszielen für die Bilder enthält. Falls kein Weiterleitungsziel gefunden wird, gebe ich einfach das Bild selbst aus.

Die redir.php PHP-Datei lasse ich mir von einem Skript durch WordPress erstellen:

<?php
define( 'THISPATH', dirname(__FILE__) . '/' );
define( 'WP_USE_THEMES', false );
define( 'USE_ATTACHMENT_URL', true );

@include( THISPATH.'redir.php' );

require('./wp-blog-header.php');

echo '<pre>';

$args = array( 'post_type' => 'attachment', 'posts_per_page' => -1, 'post_mime_type' => 'image', 'post_parent' => null ); 
$attachments = get_posts( $args );
if ( $attachments ) {
	foreach ( $attachments as $post ) {
		$attachment_url = wp_get_attachment_url( $post->ID );
		$attachment_uri = @parse_url( $attachment_url, PHP_URL_PATH );
		if( USE_ATTACHMENT_URL )
			$page = get_attachment_link( $post->ID );
		else
			$page = get_permalink( $post->post_parent );
		if( $page && $attachment_uri && !$redir_b[$attachment_uri] ) {
			if( strpos( $page, 'attachment_id' ) === false ) {
				$redir_b[$attachment_uri] = $page;
				echo "+ $attachment_uri -> $page\r\n";
			}
			else
				echo "- $attachment_uri -> $page\r\n";
		}
		else
			echo "* $attachment_uri -> $page\r\n";
	}
}

$export_data = "<?php\r\n\$redir_b = ";
$export_data .= var_export( $redir_b, true );
$export_data .= ";\r\n\r\n?>";
file_put_contents( THISPATH.'new_redir.php', $export_data );
echo '</pre>';
?>

Download: get-redir.zip

Mit der Konstante ‚USE_ATTACHMENT_URL‘ wird festgelegt, ob die Weiterleitung auf die Attachment-Seite (true) oder zur Artikel-Seite mit dem Bild (false) erfolgen soll.

Zum Anfang wird die bestehende ‚redir.php‘ geladen. Es werden dann nur Einträge hinzugefügt, die es noch nicht gibt.

Außerdem prüfe ich, ob es die Attachment-Seite wirklich gibt, denn für Bilder ohne Eltern-Seite bzw. Bilder in nicht veröffentlichten Artikeln wird kein Permalink zurückgeliefert, sonder nur die URL mit dem ‚attachment_id‘-Parameter.

Am Ende wird eine neue Datei ’new_redir.php‘ geschrieben, mit der man dann die alte ‚redir.php‘ ersetzen kann.

Folgende Dateien sind an der Methode beteiligt:
/rdr.php
/redir.php
/wp-content/uploads/.htaccess

In der .htaccess-Datei muß die RewriteBase entsprechend angepaßt werden:

RewriteBase /wp-content/upload

Für meine Putzlowitscher Zeitung enthält das Array etwas mehr als 2000 Einträge. Das ergibt eine Dateigröße von ca. 350k. Wer deutlich mehr Bilder in WP verwaltet, muß sich ggf. etwas anderes einfallen lasse.

So ein Array hat aber den Vorteil, daß ich darin auch beliebige, andere Weiterleitungsziele definieren kann.

Noch ein paar Tips und Hinweise

Falls sich alle Eure Bilder in einem Unterverzechnis befinden, bei WordPress z.B. /wp-content/uploads/, dann packt die .htaccess-Datei genau dort rein. Für alle anderen, normalen Seitenaufrufe wird sie dann gar nicht erst abgearbeitet.

Was irgendwie möglich ist, sollte schon in der .htaccess-Datei erledigt werden. Der Aufruf eines Skriptes, eventuell sogar mit Datenbankabfragen, kostet mehr Server-Leistung und verschlechtert die Performance.

Ihr könnt sogar unterscheiden, ob jemand den Button [Bild ansehen] angeklickt oder per Rechtsklick das Bild aufgerufen hat. Beim Rechtsklick wird ggf. vom Browser als Referer die komplette Google-Such-URL übermittelt. Das kann man zur Unterscheidung auswerten, z.B. ob der Parameter tbm=isch im Referer enthalten ist.

Das Speichern mit Rechtsklick auf das Original-Bild in der Bildersuche funktioniert nicht. Es wird die HTML-Seite des Weiterleitungs-Ziels gespeichert. :-)

Ich habe bisher nur mit wenigen Browsern getestet. Bei denen hat es aber funktionert, wie es soll.

Ich übernehme keine Haftung für Schäden, die möglicherweise durch die Umsetzung der hier vorgestellten Methoden entstehen.

11 Kommentare »

Geschützt: Für bestimmte Domains ein Ersatzbild anzeigen – meine Lösung

Dieser Inhalt ist passwortgeschützt. Um ihn anzuschauen, gib bitte dein Passwort unten ein:

Auch die Kommentare sind durch das Passwort geschützt.

Office 2010 – telefonische Aktivierung nicht mehr möglich?

MS Office 2010

MS Office 2010

Vor einiger Zeit hatte ich mal ein MS-Office 2010 gekauft. Es handelt sich um eine „Home and Student“-Version, die für die nicht kommerzielle Nutzung drei Lizenzen beinhaltet und vom Preis her durchaus angemessen war, wie ich fand.

Ja ich weiß, es gibt auch kostenlose Alternativen wie OpenOffice oder LibreOffice, aber manchaml braucht man doch das „Original“.

Auf zwei Rechnern hatte ich das MS-Office 2010 bereits installiert, also sollte noch eine Lizenz für das Notebook meiner Tochter verfügbar sein.

Die Installation zwischen den Feiertagen verlief problemlos aber bei der Aktivierung über das Internet gab es die Meldung, daß angeblich bereits alle Lizenzen verwendet würden. Ich müsse die telefonische Aktivierung durchführen, hieß es.

Darauf hatte ich aber keinen Bock und habe die Sache ins neue Jahr geschoben. Zumal man ja 30 Tage für die Aktivierung Zeit hat.

Vorgestern wollt ich nun die Aktivierung durchführen, aber was ist das?

MS-Office 2010 - telefonische Aktivierung wird nicht mehr unterstützt

MS-Office 2010 – telefonische Aktivierung wird nicht mehr unterstützt

„Die telefonische Aktivierung wird für dieses Produkt nicht mehr unterstützt.“

Na prima, und nun? Ich meinte mich zu erinnern, daß mir beim ersten Aktivierungsversuch nach der Auswahl des Landes noch die entsprechenden Telefonnummern für die Aktivierung angezeigt wurden. Sollte es einfach am neuen Jahr 2017 liegen, ab dem die telefonische Aktivierung deaktiviert wurde?

Das war einen einfachen Test wert. So habe ich das Rechner-Datum beherzt auf einen Tag im Dezember 2016 gesetzt und…

MS-Office 2010 - telefonische Aktivierung funktioniert

MS-Office 2010 – telefonische Aktivierung funktioniert

Na bitte, geht doch. Da sind sie ja wieder, die Telefonnummern:

Mobil oder gebührenpflichtig: +49 69 2222 5494
Gebührenfrei: 0800 2848 283

Über die gebührenfrei Nummer konnte ich dann die Aktivierung erfolgreich vornehmen, nachdem ich mich durch das Sprachmenü gekämpft und die vielen Ziffern auf der Telefontastatur eingetippt hatte.

„Die telefonische Aktivierung wird für dieses Produkt nicht mehr unterstützt.“ – stimmt also nicht ganz. Wir zeigen das einfach mal an und hoffen, daß der unbedarfte Nutzer eine neue Lizenz der aktuellen Version kauft, wird sich Microsoft gedacht haben.

Aber nicht mit mir! :-)

4 Kommentare »

Webhoster all-inkl jetzt mit let’s encrypt Zertifikat per 1-Klick Installation

All-Inkl – Let’s Encrypt Zertifikat installieren

All-Inkl mit Let's Encrypt Verschlüsselung

All-Inkl mit Let’s Encrypt Verschlüsselung

Seit ein paar Tagen kann man beim Webhoster All-Inkl ab dem Hostingtarif „PrivatPlus“ ganz einfach im Kundenmenü (KAS) für Domains/Subdomains ein Let’s Encrypt Zertifikat aktivieren. Durch das Zertifikat kann die Website verschlüsselt (SSL/TLS) per https aufgerufen werden.

Diese neue Möglichkeit wird auf der Website des Hosters noch gar nicht kommuniziert, man findet den Hinweis als Bestandskunde im KAS (siehe oben).

Die Einrichtung des Zertifikats ist im KAS mit ein paar Klicks erledigt. Man geht zum Menüpunkt „Domain“ bzw. „Subdomains“, wählt bei der gewünschten Domain als Aktion „Bearbeiten“ und klickt dort bei „SSL Schutz“ auf das Plus-Symbol.

All-Inkl: SSL-Schutz mit Let's-Encrypt

All-Inkl: SSL-Schutz mit Let’s-Encrypt

Nun wählt man oben den Reiter „Let’s Encrypt“, setzt das Häkchen bei „Haftungsausschluss akzeptieren“ und klickt auf den Button [jetzt ein Let’s Encrypt Zertifikat beziehen und einbinden]. Nach wenigen Minuten ist die Webseite per https aufrufbar. Einfacher geht es wirklich nicht. :-)

Das war’s?

Nein, das war es noch nicht. :-)

Es ist erstmal nur die halbe Miete, denn nun muß man auch noch die Webseite auf https umstellen. Der Aufruf der Seite ist nun zwar direkt per https möglich, aber alle internen Links und eingebundenen Ressourcen sind, sofern „fest verdrahtet“, noch nicht auf die Verschlüsselung umgestellt.

Bei WordPress z.B. muß man in den Allgemeinen Einstellungen noch die URLs auf https ändern und in der Datenbank per Suchen und Ersetzen für alle internen URLs das http durch https ersetzen.

Auch extern eingebundenen Ressourcen wie YouTube-Videos und Bilder müssen nun per https aufgerufen werden, sonst werden sie möglicherweise gar nicht angezeigt oder erzeugen Fehlermeldungen.

Außerdem ist es sinnvoll, die nicht https-Zugriffe per 301 auf die verschlüsselten URLs weiterzuleiten. Das wird z.B. so in der .htaccess-Datei erledigt:

<IfModule mod_rewrite.c>
RewriteEngine On
# HTTPS erzwingen 
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Alles im grünen Bereich

SSL-Labs Rating A

SSL-Labs Rating A

Der Lohn für die Mühe, beim SSL-Labs-Test wird ein grünes A-Rating angezeigt.

Allerdings sollte man den blauen Hinweis unten beachten, denn es kann Probleme mit älteren Betriebssysten, Webbrowsern oder Diensten geben. Grund ist die fehlende Unterstützung für die „Server Name Indication“ (SNI).

In Shared-Webhosting-Umgebungen, bei denen sich viele Domains eine IP-Adresse teilen, ist es prkatisch nur mit SNI möglich, eine derart einfache https-Nutzung anzubieten.

Will man auf SNI verzichten, muß man jeder per Verschlüsselung aufrufbaren Domain eine eigene IP-Adresse zuweisen oder im Zertifikat eine Liste mit alternativen Namen (subjectAltName, SAN) für alle Domains führen. Dafür müßte das Zertifikat jedesmal erneuert werden, wenn eine weitere Domain hinzu kommt. Keine wirklich partikable Lösung.

SNI ist an sich nichts Schlechtes, man sollte nur wissen, daß es Probleme geben kann.

Gut gemacht, All-Inkl!

Mit dem Webhosting bei All-Inkl bin ich schon lange sehr zufrieden. Die neue Möglichkeit, einfach im KAS mit wenigen Klicks ein Let’s Encrypt Zertifikat zu aktiviern, ist ein Schritt in die richtige Richtung und bestärkt mich mal wieder in meiner Ansicht, daß All-Inkl ein sehr gute Wahl beim Webhosting ist.

1 Kommentar »

Meine technische Bilder-Hotlink Abwehrstrategie

Heiße Links

Hotlink Infografik

Hotlink Infografik

Martin Mißfeldt vom Tagseo-Blog hat gerade einen Artikel zum leidigen Thema Bilder-Hotlinks veröffentlicht. Dort erklärt er noch einmal recht anschaulich, was Hotlinks sind, wie sie funktionieren und wie Google damit umgeht.

Auch ich habe mich schon öfter mit dem Thema beschäftigt.

Zur technischen „Abwehr“ von Hotlinks gibt es einige Möglichkeiten, die ich im Artikel „Bilderdiebe – was ich dagegen tue“ bereits erläutert habe. Im wesentlichen habe ich das auch so beibehalten, technisch nur etwas verfeinert.

Bilder-Hotlink Abwehr

Ich fahre eine Black-List Strategie, daß heißt, Hotlinks werden nur von bestimmten Domains mit einem Ersatzbild behandelt.

So sieht der entsprechende Code z.Z. in der .htaccess-Datei aus.

# Bilderdieb
RewriteCond	%{HTTP_REFERER}	^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/ [NC]
RewriteRule	.* - [E=DOM_REFERER:%1]
RewriteCond	%{REQUEST_FILENAME} -f
RewriteCond	%{REQUEST_URI}	!^/images/ersatzbild.png$
RewriteRule	\.(jpg|gif|png)$	-	[NC,C]
RewriteCond	%{ENV:DOM_REFERER}	\.tk$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	\.xyz$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	\.cf$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	mydealz\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.	/images/ersatzbild.png	[T=image/png,L]

Da ich in erster Linie bestimmte Domains (auch TLDs) ausschließen will, extrahiere ich zunächst den Domain-Namen aus dem Referrer und speichere ihn in einer Umgebungsvariable (Zeile 1 und 2).

Nur wenn es das Bild gibt (Zeile 3), es nicht das Ersatzbild ist (Zeile 4) und es überhaupt ein Bild ist (Zeile 5), werden die nachfolgenden Regeln abgearbeitet.

Es folgt die Liste der nicht erlaubten Domains bzw. Top-Level-Domains (TLD). Da der massive Hotlink-Spam zur Zeit vorzugsweise von .tk, .xyz und .cf TLDs kommt, stehen diese in der List. Die Domain mydealz.de habe ich nur zu Testzwecken aufgenommen. So kann ich sehen, ob meine Hotlink-Abwehr funktioniert. :-)

In der letzten Zeile wird dann das Ersatzbild ausgeliefert. Hier wird der Bildtyp auf png geändert, weil mein Ersatzbild ein PNG-Bild ist.

Der Haken an der Sache

Die Sache hat nur einen Haken. Die großen Hotlink-Farmen interessiert es nicht, was da letztendlich für Bilder auf ihren Spam-Seiten angezeigt werden. Ich vermute, daß die Seiten automatisch oder teilautomatisch aus den Bildern der Bildersuchergebnisse erstellt werde. Insofern bringt hier die „Abwehr“ per .htaccess herzlich wenig.

Aber egal, falls dann doch mal jemand auf die Spam-Seite kommt, sieht derjenige wnigstens nicht meine Bilder und es sieht mit dem Ersatzbild zumindet komisch aus. :-)

Hotlinks mit der Google Bildersuche finden

Mit einigen Abfrage-Parametern kann man mit der Google-Bildersuche Hotlinks auf Bilder finden.

Für die Bildersuche ergibt die Kombination

inurl:http://seite-a.de -site:seite-a.de

Treffer mit einem Bild von Seite A, welches nicht auf Seite A zu sehen ist. Das ist bei Hotlinks und Links der Fall.

Man kann aber auch gezielt nach Hotlinks von einer bestimmten Seite suchen:

inurl:http://seite-a.de site:seite-b.de

Damit werden Bilder von Seite A angezeigt, die von Seite B gehotlinkt bzw. gelinkt werden.

Für eine schnellere Übersicht könnte man die Ausgabe auf das alte Layout mit dem Parameter sout=1 erzwingen, zudem liefert die Abfrage in Abhängigkeit von der Sprache und den SafeSearch-Einstellungen bisweilen andere Ergebnisse.

Damit ihr euch die kompliziert Abfrage nicht per Hand zusammenbasteln müßt, habe ich ein Formular mit etwas Javascript drum herum erstellt. Damit kann die Hotlinksuche bequem erstellt werden.

Das Hotlink-Suchformular

Damit das Formular sichtbar ist und funktioniert, muß Javascript aktiviert sein.

In Domain kommt die Ursprungsseite der Bilder, falls es eine Subdomain ist, muß diese mit angegeben werden (z.B. images.seite-a.de).

Bei Weitere Seiten kommen die mit Leerzeichen getrennten Namen von Seiten rein, für die mit (●) ausschließen keine Hotlinks angezeigt werden sollen. Ist (●) einschließen ausgewählt, wird die Logik umgedreht. Es werden dann nur Hotlinks von den angegebenen Seiten angezeigt.

Die Optionen sind selbsterklärend, würde ich sagen.

Auf [Los] gehts los. Es wird ein neues Browserfenster mit der erstellten Google-Suche geöffnet. Falls das Fensteröffnen in den Browsereinstellungen nicht erlaubt ist, kann auch der links eingeblendete Link „Hotlinks finden“ angeklickt werden.

Ich will auch einen wesentlichen Nachteil der inurl:-Suche gegenüber der imagesite:-Suche nicht verschweigen. Die site:– bzw. frühere imagesite:-Abfrage beziehen sich tatsächlich auf den Domainnamen der Seite. Die inurl:-Abfrage ist da, wie der Name auch erwarten läßt, deutlich größzügiger.

Die Abfrage

inurl:http://seite-a.de

findet auch Bilder wie z.B.

http://seite-b.de/screenshot/?s=http://seite-a.de

Das ist natürlich kein Hotlink oder Link zur Ursprungsseite. Aber solche Treffer muß man dann einfach ignorieren.

Und was macht Ihr so gegen Hotlinks, wenn Ihr sie gefunden habt?

5 Kommentare »

Bilder-Hotlink-Spammer werden immer dreister

Bilder Hotlinkfarmen

Die normalen Bilder-Hotlinkfarmen mit den .xyz- und .tk-Domains binden üblicherweise 5 bis 10 Top-Bilder aus der Bildersuche auf ihren Spam-Seiten ein. Manchmal gibt es noch ein bißchen Text dazu, aber das war es dann auch schon.

Etwas anders sieht das im folgenden Beispiel aus.

Bilder-Spam Schokolade (versteckt)

Bilder-Spam Schokolade (versteckt)

Wenn man über die Google-Bildersuche auf eine Seite wie oben zu sehen kommt, wird man erstmal stutzig.

Gut, das in der Bildersuche angezeigte Bild ist dort nicht mehr zu sehen, es wurde scheinbar auf Grund von Urheberrechtsproblemen entfernt. Dann ist ja alles bestens, könnte man meinen.

Aber denkste, das Bild ist zwar für den Benutzer nicht sichtbar, aber trotzdem noch vorhanden (war es schon immer). Der Google-Bot „sieht“ es auch und Google schickt deshalb die Suchenden zu dieser Hotlink-Spam-Seite, und nicht zur eigentlichen Seite mit dem Bild.

Und es ist nicht nur ein Bild, es sind deren 300, die auf den Seite pro Suchbegriff verhotlinkt werden. Damit der Nutzer sie nicht sieht, sonder nur diesen „Foto auf Antrag des Inhabers der Urheberrechte entfernt“-Blödsinn, befinden sich alle Bilder in einem großen div-Element, das per css mit position:absolut und top:-999999px „unsichtbar“ gemacht wurden.

Nimmt man die css-Positionierung weg, sieht das Ganze so aus:

Bilder-Spam Schokolade

Bilder-Spam Schokolade

Wobei der Screenshot nur die ersten Bilder zeigt, der „Pearl Crescent Page Saver“ stürzt beim Speichern der ganzen Seite ab. Auch „Full Page Screen Capture“ in Chrome scheitert an der riesiegen Seite mit den vielen Bildern.

Google DMCA-Beschwerdestelle ausgetrickst

Es gibt nicht viele Möglichkeiten, gegen diesen massiv zugenommenen Bilder-Hotlink-Spam vorzugehen.

Man kann bei Google einen Spam-Report erstellen, der aber praktisch gar nicht bewirkt. Man kann die Seiten im Google-Webmasterforum verpetzen und falls Sven das mitbekommt, werden solche Seiten eventuell manuell aus dem Index entfernt.

Oder man reicht eine DMCA-Beschwerde bei Google ein. Dort muß man das Bild beschreiben, eine URL für eine autorisierte Verwendung des Bildes und die URL mit der Urheberrechtsverletzung angeben.

Ich weiß jetzt nicht genau, wie die eingereichten Daten bewertet werden, aber wenn da eine Mensch sitzt und sich die URLs ansieht, wird er den Antrag vermutlich ablehnen, weil er das Bild auf der urheberrechtsverletzenden Seite nicht finden kann.

Erschwerend kommt hinzu, daß die Bearbeitung 10 Tage bis 2 Wochen dauert und bis dahin die Spammer schon längst auf eine neue Domain umgezogen sind. :-(

Dabei wäre die Lösung so einfach.
Google muß einfach aufhören, derartige Hotlinkseiten so gut zu ranken. Der Ranking-Algorithmus der Google-Bildersuche ist zur Zeit krank, schwer krank, würde ich sagen. Ob es noch Hoffnung auf Genesung gibt, ist fraglich.

10 Kommentare »

CMOS (BIOS) Batterie wechseln, Intel Desktop Board DB65AL

PC CMOS-Batterie (BIOS-Batterie)

PC CMOS-Batterie (BIOS-Batterie)

Normalerweise halten CMOS-Batterien, die die BIOS-Einstellungen auf Mainboards auch bei Stromabschaltung am Leben erhalten, recht lange. Ich mußte bei den PCs, die ich bisher hatte, noch keine dieser BIOS-Batterien wechseln.

Wenn man aber einen Rechner nur gelegentlich nutzt und ihn zudem per Verteiler mit Schalter richtig vom Stromnetz trennt, dann ist die Batterie möglicherweise schon nach ca. 3 Jahren verbraucht. Durch das netzseitige Abschalten wird die Standby-Spannung nicht mehr erzeugt und so muß die BIOS-Batterie die längste Zeit die Versorgung der Einstellungen übernehmen.

Kürzlich stand ein CMOS-Batteriewechsel bei einem Rechner an und da ich ihn auf Grund der räumlichen Entfernung nicht selbst ausführen konnte, habe ich ein kurzes Anleitungs-Video erstellt:

Beim Intel Desktop Board DB65AL befindet sich der Batteriehalter nicht wie bei vielen Boards unten oder zwischen den Erweiterungs-Steckplätzen (siehe Bild), sondern oben rechts neben den Speichermodulen. Außerdem ist es keine liegender, sondern ein stehender Batteriehalter.

Benötigte Batterie: CR 2032

Vorher: PC ausschalten und vom Netz trennen

So gehts:
Den oberen Rand der Halterung vorsichtig nach oben/hinten drücken, bis die Batterie zur Seite herausklappt. Nun die Batterie entnehmen und die neue Batterie unten in den Halter einsetzen, so das die Seite mit der Beschriftung nach rechts zeigt. Die CR-2032 oben in die Halterung drücken. Fertig! :-)

1 Kommentar »