Nov 11

Permalinks, und wie der derWesten damit umgeht

Allgemein, Meschede No Comments »

Ab und an schaue ich mal bei “derWesten” vorbei um die neuesten Dinge aus meiner alten Heimat zu lesen. Seit ca. 3 Wochen hat man bei dW das alte Newsportal durch ein neues ersetzt.

Zur Erinnerung: Das alte WebPortal machte einen auf “blog”. Es gab dort bspw. (lieblos funktionierende) Trackbacks, die zwar in den Kommentaren hier und da auftauchten, bei denen man aber krampfhaft nach der Trackback-URL suchen musste. Ferner hatte ich den Eindruck, dass nichtmal die (Lokal-)Redakteure selbst wussten, wann und wie ein Beitrag im Inhaltsverzeichnis geranked wurde. So waren z.B. Artikel, die auf ein Event am nächsten Tag hinwiesen, sogar nach Monaten noch prominent auf der (Lokal-)Titelseite sichtbar. Andere, durchaus kontrovers diskutierten, Artikel schon nach 5h wieder verschwunden. (Irgendwie muss es der CvD also doch beeinflussen können)

Wie sich das ganze mit dem neuen Online-Redaktionssystem auswirkt, mag ich noch nicht beurteilen, zumal ich, wie oben erwähnt, nur alle Jubelwochen dort mal vorbeischaue. Sämtliche gesetzte Bookmarks und Trackbacks sind mit dem Softwareupdate allerdings ungültig geworden, da man bei derWesten anscheinend den Begriff permalink nicht begriffen hat.

Beim letzten Aufruf von derWesten traf mich jedoch ein leichter Schlag. Jetzt muss ich vorher allerdings etwas ausholen: Ich habe hier zu hause, zusätzlich zum AdBlocker, einen Privoxy installiert. Der springt bei diversen Keywords und suspekten Seiten an, und blockiert dann, Serverseitig (also im Proxy), den entsprechenden Request. Ich rufe also derWesten, über mein nicht aktualisiertes Bookmark, auf, um dann direkt mal auf den erstbesten Artikel zu springen. In diesem Moment meldet mein Privoxy sinngemäss “Nee, ist nicht, weil da was mit ads (Werbung) vorkommt”.

Der Link, der mir da entgegensprang, sah schon suspekt aus (irgendwas mit xiti.com), sodass ich mir das mal näher angesehen habe. Im HTML der Seite steht noch ein normales href, also ein “Deeplink” auf den Artikel. Ein Redirect findet auch nicht statt. Woher kam also dieses “xiti.com” gedönse. Des Rätsels Lösung findet man in einem mitgeladenen Javascript, mit dem sprechenden Namen “click.js”. Die “Entwickler” von derWesten haben sich einfach in den onClick Handler vom Link eingeklinkt. Jedesmal wenn von dieser Seite ein Link aufgerufen wird, manipuliert ein Stück Code von derWesten die Umleitung via “xiti.com” darein. Na Toll !!

Der Erste Gedanke war: Gibt’s jetzt schon Werbeanbieter die das anclicken im eigenen Angebot incentivieren ? Nein, gibt es natürlich nicht. xiti.com ist ein Anbieter der, festhalten – und jetzt versteht Ihr warum ich oben so weit ausgeholt habe – die Struktur einer Site optimieren soll. Mit anderen Worten läuft das wie folgt, wenn ich es richtig verstanden habe: derWesten schaltet dieses xiti.com immer dann dazwischen, wenn der User einen vermeintlich toten Link aufgerufen hat, um herauszufinden, was der Anwender denn wollte.

Das muss man sich mal vorstellen. Da lässt sich dieses WAZ-Blättchen ein komplett individualisiertes CMS zusammenbretzeln, dass vor Javascript-Foo nur so strotzt, und dann nehmen die für Analysen einen 302er Redirect über einen Amiland-Anbieter in Kauf ? So ein include, o.ä. hätte es sicher auch getan.

Naja, wenn dann xiti.com abraucht, dann zieht’s derWesten halt gleich mit.

Tagged with: • • • •
Dez 29

URL Rewriting mit dem Squid

Fun, Linux, Netz No Comments »

Aufmerksam geworden durch diesen Artikel, mit dem ueber den Proxy geholte Webseiten (genauer gesagt werden alle Images einmal um 180 Grad gedreht) on the Fly manipuliert werden habe ich mir das ganze mal näher angesehen und optimiert.

Vorweg schonmal das Ergebnis (funktioniert TRANSPARENT mit allen JPGs, GIFs und PNGs). Transparent bedeutet in diesem Falle, dass der Anwender in keinerlei Weise mitbekommt, dass es sich hier um ein manipliertes Bild handelt. Die Requests werden quasi 1:1 durchgeleitet.

Wor moechten also alle Bilder, die aus dem LAN via Proxy angefordert werden, einmal um 180 Grad drehen. Folgende Ausgangssituation:

  • Transparenter Squid auf einem Router
  • Webserver auf einem etwas dickeren Rechner im LAN

in /etc/squid/squid.conf folgende Zeile einfügen:

url_rewrite_program /usr/bin/updwn.pl
url_rewrite_children 5

Das File /usr/bin/updwn.pl sollte wie folgt aussehen:

#!/usr/bin/perl
# Runs as proxy:proxy
# input - siehe unten (Array params)
# output - URL - transparent *invisble to Enduser :-) *
$|=1;
while (<>) {
chomp $_;
@params=split(/ /,$_);
# 0 = Request URL
# 1 = Requesting IP/-
# 2 = -
# 3 = Request Method
# 4 = myip= ?
# 5 = myport = ?
$url=$params[0];
if (!($params[1]=~/192\.168\.60\.200/)) { # Nicht rekursiv aufrufen (Boese !!)
$url='http://192.168.60.200/ppics/updwn.pl?u='.$url if ( ($url=~/gif/i) || ($url=~/jpg/i) || ($url=~/jpeg/i) || ($url=~/png/i));
}
print $url."\n";
$count++;
}

Wobei die 192.168.60.200 durch die IP des eigenen Webserver zu ersetzen waere. Die eigentliche “Magie” findet naemlich jetzt im updwn.pl auf dem Webserver statt. Das Ding benutzt, im gegensatz zu dem File, welches in dem Artikel beschrieben wurde, direkt die GD-Library und ruft keinerlei Executables mehr auf. Damit ist das Script ein wenig performanter

Hier der Inhalt von /var/www/ppics/updwn.pl:

use CGI qw/:standard/;
use LWP::UserAgent;
use GD;
binmode STDOUT;

$|=1;
my $url=param(“u”);

chomp $url;
my $ctype=”;
my $content=”;
get_content($url,\$ctype,\$content);
rotate(\$content,\$ctype) if ($ctype=~/image/i);
print “Content-Type: “.$ctype.”\n\n”;
print $content;
print “\n–magicalboundarystring\n” if ($ctype=~m/image/);

sub get_content {
my ($url,$ref_ctype,$ref_content)=@_;
my $ua = LWP::UserAgent->new;
$ua->agent(“MyApp/0.1 “);
my $req = HTTP::Request->new(GET => $url);
my $res = $ua->request($req);
$$ref_ctype=$res->content_type;
$$ref_content=$res->content;
}

sub rotate {
my ($ref_content,$ref_header)=@_;
my $image=undef;
$image=newFromPngData GD::Image($$ref_content) if ($$ref_header=~/png/i);
$image=newFromJpegData GD::Image($$ref_content) if ($$ref_header=~/jpeg/i);
$image=newFromGifData GD::Image($$ref_content) if ($$ref_header=~/gif/i);
$image->rotate180();
$$ref_header=’image/png’;
$$ref_content=$image->png();
}
Wichtig: Die URL sollte nicht aus dem Internet erreichbar sein. Ansonsten hat man einen selbstgebastelten offenen Proxy…

Mithilfe der Parameter des Files /usr/bin/updwn.pl kann man sich jetzt sogar lustige ACLs bauen. (Rotiere nur fuer bestimmte IP’s oder fuer bestimmte URLs, etc…) Der Phantasie sind da keine Grenzen gesetzt.

Tagged with: • • • • • • • • • •
preload preload preload