29. Juli 2010

Probleme beim Umstieg auf PHP 5.3…

Abgelegt unter: something completely different | — Tags:, , — admin @ 09:11

Beim Großteil der Webseitenbetreiber ist das Problem der als deprecated eingestuften Funktionen ab PHP 5.3 noch kein Thema da die meisten großen Hoster Ihre Webpakete noch gar nicht umgestellt haben. Inwiefern dieselbe Lücke entstehen wird wie es bei PHP 4 der Fall war, hier wurde sehr lange mit einer Aktualisierung der Pakete gewartet) wird sich zeigen.

Nichtsdestotrotz wird bei einigen Hostern die neueste Version angeboten, viele Systeme werden entsprechende Fehlermeldungen erzeugen.

Auch Shopbetreiber werden dieses Problem mitbekommen, verwenden doch die meisten Shopsysteme (eine oberflächliche Stichprobe ergab beispielsweise Probleme bei osCommerce, olCommerce, Oxid CE, commerce:SEO, eComBASE, xt:Commerce, FWP Shop sowie Magento und, wenn auch nur an wenigen Stellen, Prestashop um nur einige zu nennen die in der jeweils neusten Version vorlagen, ältere Versionen werden vermutlich alle Probleme machen) Funktionen die ab PHP Version 5.3 Fehler auswerfen.

Besonders heikel sind hierbei die regex Funktionen da diese an vielen Stellen eingesetzt werden an denen Entscheidungen für den ein oder anderen Codeblock getroffen werden müssen. Aber auch elementare Funktionen für die Erzeugung und das Management von Sessions sind davon betroffen und können dazu führen das die Shopsysteme unbrauchbar werden.

Den Ansatz einfach die Fehlermeldungen zu unterdrücken werden vermutlich viele Provider und Shopbetreiber nutzen, allerdings wird dies spätestens ab PHP 6 zu schweren Problemen führen da die Funktionen selbst dann wohl schlicht nicht mehr funktionieren werden. Um einen Umbau der vorhandenen Software, also einen Austausch der betroffenen Funktionen mit den entsprechenden Pendants wird man also nicht herum kommen.

Eine Liste der Features die als deprecated eingestuft wurden findet sich übrigens hier : http://php.net/manual/en/migration53.deprecated.php

Ebenfalls als schwierig dürften sich die dadurch in diversen externen Komponenten enthaltenen Problemfunktionen, beispielsweise bei Spaw, Nusoap oder den phpMailer Klassen erweisen da diese Komponenten in zahlreichen Produkten Ihren Dienst tun. Problematische Funktionen finden sich auch in vielen Contributions beispielsweise für osCommerce.

Bekannt ist das Auslaufen der Funktionen eigentlich seit geraumer Zeit, aber bislang reagieren die meisten Systemhersteller nicht bzw. nur mit dem Hinweis die Fehlermeldungen einfach zu unterdrücken.

Übrigens, auch my-Warehouse musste für den Einsatz unter PHP 5.3 erst fit gemacht werden. Die Arbeiten daran sind aber mittlerweile abgeschlossen worden.

30. März 2010

Unliebsame Spambots am Beispiel von referertrick.com/referertrick.de/referertrick.net aussperren TEIL 2…

Abgelegt unter: something completely different | — Tags:, , , , , , , , , , , , , , , , , , , — admin @ 08:53

Auch nach dem Artikel auf unserem Blog, und dem reichlichen Zuspruch dazu scheint man bei referertrick.com/net/de keine Notwendigkeit zu sehen mit der Spamerei wenigstens für bestimmte Domains aufzuhören.

Das finden wir sehr ärgerlich, zumal wir die entsprechenden Domains im “Sperrformular” auf der Seite eingetragen haben, Wirkung ganz offenbar Null.

Möglicherweise muss man, da man den Anbieter offenkundig nicht dazu bringen kann die Spamerei zu unterlassen, die Kunden des Unernehmens auf Ihr Tun und die daraus entstehenden Folgen hinweisen. Übrigens, teilweise wird sogar öffentlich gemacht welcher Kunde gerade von welchem Server aus Webseiten mit Werbespam zuschüttet. Schon recht mutig sich auf diese Weise sozusagen öffentlich an den Pranger zu stellen.

Um dem Kunden einen entsprechenden Hinweis zu hinterlassen adaptieren wir die Technik die das Unternehmen benutzt, mit einer kleinen Erweiterung des ursprünglichen PHP Skriptes ist es möglich auf Spamrequests mit einer entsprechenden Antwort zu reagieren.

Im Beispiel schauen wir nach von welcher IP der Request kommt, stehen unsere 3 bislang erkannten IPs (Server 4 wurde, zumindest bei uns, noch nie benutzt, möglicherweise mangels Aufträgen?) als Absender fest schicken wir einen HTTP Request mit manipuliertem Referrer heraus der übrigens das Minimum an Last erzeugt da lediglich der HTTP Header gesendet aber keinerlei Daten angefordert werden. Um möglicherweise gestressten Systemen nicht weitere Last zuzumuten steht der Timeout bei 1, nach einer Sekunde wird also in jedem Falle abgebrochen. Als Referrer haben wir eine Seite genommen die klar machen soll warum es keine gute Idee ist Referrerspam zu betreiben nämlich http://www.stapis.de/nospam.html, selbstverständlich lässt sich auch eine andere Webseite einsetzen.

Hier der PHP Code :

<?php
if (getenv(’REMOTE_ADDR’) == “87.118.116.23″ || getenv(’REMOTE_ADDR’) == “87.118.82.66″ || getenv(’REMOTE_ADDR’) == “87.118.82.104″ && (getenv(’HTTP_REFERER’) != “”)) {
$parts = parse_url(getenv(’HTTP_REFERER’));
$target = $parts[host];
$fp = fsockopen($target, 80, $errno, $errstr, 1);
if ($fp) {
$out = “GET / HTTP/1.1\r\n”;
$out .= “Host: ” . $target . “\r\n”;
$out .= “Referer: http://www.stapis.de/nospam.html\r\n”;
$out .= “Connection: Close\r\n\r\n”;
fwrite($fp, $out);
fclose($fp);
}
exit;
}
?>

Dieses Skript kann man unter einem beliebigen Namen abspeichern und per include in beliebige Skripte laden. Da diesmal keine HTTP Weiterleitung ausgeführt wird muss das include nicht ganz am Anfang stehen, um Last zu vermeiden ist dies jedoch ratsam.

Nehmen wir an man speichert den obigen Codeschnipsel unter dem Namen “returning_message.php” würde der include Befehl also so aussehen :

include(”returning_message.php”);

Im Ergebnis bekommt der “Werbetreibende” einen Request zugesendet in dem die festgelegte Webseite als Referrer angegeben wird, was in den Logs desjenigen auftauchen sollte. Das passiert jedesmal wenn ein Spamrequest ausgeliefert wird.

Wir wissen natürlich nicht ob das wahrgenommen wird, denn Referrerspam (und letztendlich ist es ja die gleiche Tour die der “Werbetreibende” über den “Dienstleister” ja auch nur fährt) ist natürlich eine äusserst ineffektive “Werbeform” aber immerhin kann man so einen konkreten Hinweis hinterlassen ohne den “Werbetreibenden” konkret kontaktieren zu müssen.

Wir werden übrigens, wenn die Spamrequests nicht aufhören, als nächstes die “Werbetreibenden” anrufen und nachfragen warum Sie uns eigentlich mit Werbung zumüllen. Sollte es so weit kommen werden wir in Teil 3 dieses Artikels entsprechend berichten.

22. März 2010

Unliebsame Spambots am Beispiel von referertrick.com/referertrick.de/referertrick.net aussperren…

Abgelegt unter: something completely different | — Tags:, , , , , , , , , , , , , , , , , , , , — admin @ 10:12

Bei der regelmässigen Kontrolle unserer Zugriffe stoßen wir in letzter Zeit immer öfter über Zugriffe die einen Referrer namens referertrick.com, neuerdings auch referertrick.de, ausweisen. Also kurz nachgesehen und siehe da, diese in Italien ansässige Firma bietet Werbepakete an in denen eine große Anzahl an Zugriffen auf irgendwelche nicht näher spezifizierten Webseiten verkauft werden in welchen der Referrer manipuliert wurde. Man setzt offenbar darauf das Webmaster die Referrer überprüfen, die genannten Webseiten besuchen und die Angebote der beworbenen Seite in Anspruch nehmen.

Man könnte dies eigentlich als ganz reinrassigen Referrerspam bezeichnen, es gibt ja keinen anderen Sinn als eben die “Werbebotschaft” zu überbringen, der dabei entstehendene zugegebenermaßen auf der einzelnen Domain nicht besonders große, Traffic und Performanceaufwand wird billigend in Kauf genommen. Große Provider werden das vermutlich nicht besonders lustig finden, schließlich summiert sich das je nach Anzahl der Gesamtrequetsts auf ein Netzwerk.

Ausgeführt wird ein GET Request, mutmaßlicherweise mangels Informationen über weitere existierende Webseiten, bislang immer auf die Indexdatei der jeweiligen Domain zugegriffen. Als Werbeform eigentlich komplett ungeeignet da die Konversionsrate selbst bei Millionen ausgeführter Requests (die wie wir feststellen konnten offenbar auch nicht besonders effizient verteilt wurden, wir hatten auf einer Domain bis zu 8 Zugriffe am Tag) stark gegen Null tendieren dürfte, seriöse Anbieter sich dabei zudem bei dem Großteil der Webmaster die Kenntnis von der Vorgehenswese nehmen den Ruf ruinieren dürften.

Wir haben uns über die immer häufigeren Zugriffe geärgert und den Anbieter kontaktiert, darum gebeten von den Zugriffen ausgeschlossen zu werden. Zudem haben wir genau diesen Artikel angekündigt sollte dies nicht geschehen, schließlich haben wir auch noch diverse Kundenseiten die es vor solch unliebsamen Zugriffen zu schützen gilt.

Daraufhin stellte der Anbieter ein Formlar zur Verfügung in das wir alle zu Domains auf die nicht mehr zugegriffen werden sollte eintragen konnten. Ein ziemlich aufwendiges Verfahren wenn man mehr als eine Domain hat. Wie auch immer, wir probierten dies, allerdings komplett ohne Erfolg, die Zugrife kamen weiterhin und nun lösen wir unser Versprechen ein.

Nach Aussagen der Webseite verfügt die Firma zur Zeit über 4 Server welche die Zugriffe ausführen.

Wir konnten die folgenden 3 IP Adressen identifizieren:

87.118.116.23
87.118.82.66
87.118.82.104

Von diesen 3 IPs stellten wir die Zugriffe fest, als Useragent wurde immer “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0)” verwendet, ob das eine Konstante ist lässt sich schwer sagen, in jedem Fall kann man aber etwas über die IP Adressen tun.

Einfachster Weg wäre die Webseite per .htaccess gegen Zugriffe von den genannten IPs zu schützen. Angenehmer Nebeneffekt ist das nicht nur der Traffic und die Last wegfält sondern auch die Übertragung der Werbebotschaft verhindert wird.

Dazu im Wurzelverzeichnis der jeweiligen Domain eine Datei namens .htaccess anlegen und folgenden Inhalt einfügen:

order allow,deny
deny from 87.118.116.23
deny from 87.118.82.66
deny from 87.118.82.104
allow from all

Selbstverständlich lassen sich bereits bestehende .htaccess Dateien entsprechend erweitern, dazu einfach die “deny from …” Zeilen einfügen.

Ein etwas eleganterer Weg wäre es den Zugriff umzulenken, besonders interessant dabei wäre es natürlich den Zugriff auf die Domain des Dienstes zu lenken, sollte die Weiterleitung durchgehen spamt sich der Dienst selbst zu.

Auch das lässt sich über die .htaccess abbilden und zwar mit den folgenden Zeilen:

RewriteEngine On
RewriteBase /
RewriteCond %{REMOTE_HOST} ^87\.118\.116\.23$ [NC] # referertrick.com spamserver 1
RewriteCond %{REMOTE_HOST} ^87\.118\.82\.66$ [NC] # referertrick.com spamserver 2
RewriteCond %{REMOTE_HOST} ^87\.118\.82\.104$ [NC] # referertrick.com spamserver 3
RewriteRule .* http://www.referertrick.com [F,L]

Natürlich gibt es auch Webpakete in denen ein editieren der .htaccess nicht möglich ist.

Kein Problem solange PHP nutzbar ist, ein paar Zeilen Code, ein include Aufruf mehr ist nicht notwendig:

Beispiel :

<?php
if (getenv(’REMOTE_ADDR’) == “87.118.116.23″ || getenv(’REMOTE_ADDR’) == “87.118.82.66″ || getenv(’REMOTE_ADDR’) == “87.118.82.104″) {
header(”Location: http://www.referertrick.com”);
exit;
}
?>

Diesen Code kann man in eine Datei beispielsweise namens “botstop_incl.php” ablegen die man dann wiederum per include Befehl in den jeweiligen Scripten (aufgrund der Vorgehensweise des Spambots bevorzugt auf dem Indexscript) einbinden könnte.

include(”botstop_incl.php”);

Diese Anweisung muss ausgeführt werden bevor irgendeine Ausgabe erfolgt um eine funktionierende  HTTP Weiterleitung zu gewährleisten.

Diese Vorgehensweise verhindert zwar nicht den Zugriff und damit die Aufzeichnung in den Serverlogs, allerdings leitet Sie den Bot auf die eigene Webseite weiter. Sollte der Bot auch nur ein Mindestmaß an Logik besitzen sollte er feststellen das der Zugriff offenkundig nicht hinhaut und mit der Spamerei aufhören. In der Praxis hat sich eine solche Vorgehensweise bislang ganz gut bewährt.

Ebenfalls möglich wäre es den Request auf die beworbene Webseite umzulenken:

<?php
if (getenv(’REMOTE_ADDR’) == “87.118.116.23″ || getenv(’REMOTE_ADDR’) == “87.118.82.66″ || getenv(’REMOTE_ADDR’) == “87.118.82.104″) {
header(”Location: ” . getenv(’HTTP_REFERER’));
exit;
}
?>

Gleiches Vorgehen, der Dienst spamt dann allerdings die Webseite seines Auftraggebers. Ob der darüber begeistert sein wird, wer weiß…

Noch fehlt uns die 4. IP Adresse, Leser sind herzlichst eingeladen diese per Kommentar zu melden.

8. Februar 2010

Sparklines PHP Libary für transparente Hintergründe erweitern…

Abgelegt unter: something completely different | — Tags:, , , , , — admin @ 09:31

Die Sparklines PHP Bibliothek ist eine feine Sache um zeitliche Verläufe auf kleinstem Raum zu illustrieren, diverse Funktionen ermöglichen auch eine Anpassung des Bildes an die Webseite auf der es präsentiert werden soll, leider gibt es aber keine Funktion für transparente Hintergründe.

Die folgenden Schritte zeigen wie man dieses Problem einfach und schnell löst, die nächsten Versionen der Sparkline Bibliothek für PHP werden die Lösung eventuell bereits anbieten können (Code wurde an den Projektbetreuer übermittelt), für den aktuellen Stand aber müssen noch ein paar Dinge angepasst werden.

1. Laden Sie die aktuelle Version der Sparkline PHP Bibliothek herunter (http://sourceforge.net/project/showfiles.php?group_id=122936), entpacken Sie das Archiv in einen Ordner Ihrer Wahl.

2. Öffnen Sie mit einem Editor die Datei Sparklines.php.

3. Fügen Sie die folgende Funktion ein :
function setTransparency () {
$this->colorTransparency = “1″;
} function setTransparency

4. Suchen Sie die Funktion DrawBackground, und ersetzen Sie die komplette Funktion mit dem folgenden Code :

function DrawBackground($handle = false) {
$this->Debug(”Sparkline :: DrawBackground()”, DEBUG_DRAW);
if (!$this->IsError()) {
if ($handle === false) $handle = $this->imageHandle;
$this->DrawRectangleFilled(0,
0,
imagesx($handle) - 1,
imagesy($handle) - 1,
$this->colorBackground,
$handle);
if ($this->colorTransparency == “1″) {
imagecolortransparent($handle, $this->colorList[$this->colorBackground]['handle']);
}
}
} function DrawBackground

5. Speichern Sie die Datei.

Die Bibliothek kann nun gemäß Dokumentation (http://sparkline.wikispaces.com/usage) verwendet werden, um Transparenz hinzuzufügen muss lediglich die Methode setTransparency() vor dem eigentlichen Rendern aufgerufen werden :
$sparkline->setTransparency();

Kontakt | Impressum | © by STAPIS GmbH

Hannes Peterseim fragt an ob Sie eine Beratung wünschen:

  
Chat beenden