ScriptBlogger

Der Kunden-Support von T-Online hat 'ne wirklich merkwürdige Absender-E-Mail:

From: mailerror-prod@sda.t-online.de [mailto:mailerror-prod@sda.t-online.de] On Behalf Of businesscenter-technik@t-online-business.de

Ein Anwender, der unser Galerie-Script nutzt, äußerte sich lobend über das Script und regte an, dass man es doch um eine Kommentarfunktion erweitern könnte. Wir haben ihn auf unser Kommentar-Script verwiesen.

In der E-Mail des Anwenders stand übrigens auch folgender Satz. Sollte vermutlich aufmunternd gemeint sein. ;-)

Wird vom zusätzlichem Code sicher nicht die Welt sein

Genau genommen stimmt das sogar. Die vitalen Funktionen des Comment Scripts sind in drei Dateien enthalten. Aber mit Kommentar speichern und anzeigen ist es nicht getan. Die meisten Nutzer wollen einen Admin-Bereich, um Kommentare löschen oder editieren zu können. Und dann ist da noch das leidige Problem mit Spam. Und Backups. Und, und, und.

Die Anforderungen nehmen kein Ende und am Schluss schwillt das Script auf 2 MB an. Oder genauer: Auf über 300 Dateien, 75 Verzeichnisse und 60.000 Zeilen Code. :-o

Ein Interessent für den Schedule Organizer schrieb, dass deren Web-Entwickler gerade dabei wäre, eine Online-Datenbank zur Verwaltung von Personaltrainings zu entwickeln. Dabei kam auch folgender Satz vor, denn man sicherlich vorteilhafter für den Web-Entwickler hätte formulieren können. Wenn man gewollt hätte. ;-)

However the developer needs help developing a purposed scheduling system for us.

Danach folgten noch einige undurchsichtige Erklärungen und am Ende stellte sich uns die Frage, was die nun tatsächlich suchen. Eine Terminplanungs-Software oder einen Berater, der ihnen bei der Erstellung der Software hilft? Wir sind dann mal auf die Antwort gespannt.

Auf den meisten Servern sind Index-Seiten definiert, die angezeigt werden, wenn ein Verzeichnis ohne Datei aufgerufen wird. http://www.example.com/ zeigt automatisch den Inhalt von http://www.example.com/index.html an, sofern vorhanden. Genauso gut könnte man http://www.example.com/index.html direkt aufrufen. Das Ergebnis wäre inhaltlich dasselbe.

Nicht so leider für unser Kommentar-Script. Das, nämlich, unterscheidet sehr wohl zwischen den beiden oben genannten URLs. Wenn nun Besucher die Seite mal mit index.html und mal ohne aufrufen und einen Kommentar hinterlassen, hat der Betreiber am Ende zwei verschiedene Sätze von Kommentaren, die eigentlich zusammen auf der Seite angezeigt werden sollten.

Lösen lässt sich das mit Mod Rewrite und .htaccess.

Folgender Code leitet von http://www.example.com/index.html zu http://www.example.com/

RewriteEngine on
RewriteRule index\.html / [L,R=301]

Angenommen, man hat ein oder mehrere Unterverzeichnisse, ergänzt man einfach den entsprechenden Pfad. Folgender Code leitet von http://www.example.com/test/beispiel/index.html zu http://www.example.com/test/beispiel/.

RewriteEngine on
RewriteRule index\.html /test/beispiel/ [L,R=301]

Recht hilfreich ist diese Methode auch um zu verhindern, dass solche Seiten doppelt in den Suchmaschinen landen. Stattdessen kommt nur http://www.example.com/ in den Index und nicht auch noch http://www.example.com/index.html.

Nicht nur Strato-Server trumpfen mit merkwürdigen Pfaden auf. Auch Web-Server anderer Web-Space-Provider spielen ein doppeltes Spiel.

Unser Comment Script erstellt während der Installation automatisch eine Datei, welche den Server-Pfad zum Script enthält. Den Pfad bezieht das Script dabei aus der Umgebungsvariable DOCUMENT_ROOT.

Dass man DOCUMENT_ROOT jedoch nicht ohne Weiteres trauen sollte, zeigte sich auch im folgenden Fall. Das Script eines Anwenders meldete folgenden Fehler:

Warning: include(): open_basedir restriction in effect. File(/usr/local/apache/htdocs/comments/comment.php) is not within the allowed path(s): (/home/:/usr/lib/php:/tmp) in /home/c999999/public_html/comments/include.php on line 11

Zwei Dinge, die hier auffallen. Erstens, das Script befindet sich auf einer Shared-Hosting-Maschine. Ein Pfad wie /usr/local/apache/htdocs/ passt da aber nicht ins Bild. Es fehlt die Zuordnung zu einem Kunden.

Und zweitens, beide Pfade unterscheiden sich. Zumindest der vordere Teil des Pfades sollte gleich sein. Laut Fehlermeldung aber wurde das Script unter dem Pfad /usr/local/apache/htdocs/ (laut DOCUMENT_ROOT) und unter dem Pfad /home/c999999/public_html/ (laut Fehlermeldung) installiert. Ein Script mit gespaltener Persönlichkeit?

Wohl kaum. Das Problem war gelöst, nachdem der Anwender den falschen Pfad (der aus dem DOCUMENT_ROOT kam) durch den korrekten Pfad (der durch die Fehlermeldung preisgegeben wurde) ersetzt hatte.

Kürzlich kam mit der c't wieder die Knoppicillin-Live-CD ins Haus. Damit lässt sich der eigene Rechner auf Viren überprüfen, ohne dass ein Anti-Viren-Programm installiert ist oder das Betriebssystem des Rechners überhaupt gestartet wird. Die aktuelle Knoppicillin-CD testet mit den Viren-Scannern von Avira, BitDefender und Kaspersky.

Einer unserer Rechner zeigte beim Test Auffälligkeiten. Während Avira und BitDefender zufolge der Rechner sauber war, fand Kaspersky 38 Infizierungen. Autsch.

Die Log-Datei sah wie folgt aus (Auszug):

~8:13:44 +0100]/UNNAMED///x-game.exe INFECTED Trojan-Downloader.Win32.Agent.crz
~ 14:42:00 -0500]/UNNAMED///game.exe INFECTED Trojan-Downloader.Win32.Agent.czl
~                                      .exe INFECTED Email-Worm.Win32.NetSky.aa
~ 2007 09:34:51 +0100]/UNNAMED///flash-game.exe INFECTED Trojan.Win32.Pakes.bpa
~te Tue, 20 Nov 2007 14:18:23 +0100]///card.scr INFECTED Trojan.Win32.Inject.la
~                                      .exe INFECTED Email-Worm.Win32.NetSky.aa
~ 16:09:30 -0500]/UNNAMED///card.scr INFECTED Trojan-Downloader.Win32.Agent.gbu
~ 21:24:47 +0000]/UNNAMED///card.scr INFECTED Trojan-Downloader.Win32.Agent.gbu
~ec 2007 13:50:48 -0500]///hard.scr INFECTED Trojan-Downloader.Win32.Diehard.dc
~e Mon, 19 May 2008 13:37:17 +0800]///jolie.exe INFECTED Trojan.Win32.Pakes.cwv
~Sun, 1 Jun 2008 11:57:01 +0300]///Rechnung.exe INFECTED Trojan.Win32.Buzus.hrp
~Fri, 6 Jun 2008 17:28:13 +0300]///Rechnung.exe INFECTED Trojan.Win32.Buzus.hrp

Der erste Schock war recht schnell überwunden, als der Blick auf den Pfad fiel. Alle gefundenen Trojaner und Würmer befanden sich unter folgendem Pfad (geändert):

/server/mysql/data/beispiel_projekt/data.MYD

Data.MYD ist eine Tabelle der MySQL-Datenbank eines Projektes. Dieses Projekt empfängt eine Menge E-Mails - inklusive Spam-, Trojaner- und Wurm-E-Mails. Auch wenn die in der Datenbank befindlichen Trojaner kein besonders großes Schadenspotenzial beinhalten, wäre es vielleicht trotzdem eine gute Idee gewesen, die Datenbank zu bereinigen, bevor man sich einen Dump vom Server herunterlädt. Na ja, nächstes Mal. ;-)

Kaspersky verdient sich damit einen Bonuspunkt als einzige Antiviren-Software der drei Kandidaten, die Trojaner/Würmer in MySQL-Datenbanken findet.

Ein guten Rutsch und ein frohes und gesundes neues Jahr wünschen wir allen Lesern und Kunden.

Unser News Script hatte sich gegen die Installation durch einen Kunden gesträubt und ließ sich erst durch unseren Eingriff zur Arbeit überreden. Der Kunde schrieb dann:

Mein Dank wir dir ewig nachschleifen!

Ob man das aber tatsächlich möchte? ;-)

Vielleicht ist es ja Absicht, aber auf jeden Fall ist es merkwürdig und auf keinen Fall ist es etwas, was man erwarten würde. Folgende Konstellation: Eine Kundin betreibt seit einiger Zeit Webpräsenz ABC-BEISPIEL.de. Der DOCUMENT_ROOT dafür lautet in etwa wie folgt:

/home/strato/www/a/www.abc-beispiel.de/htdocs

So weit so unspektakulär. Nun hat die Kundin eine weitere Domain (XYZ-BEISPIEL.de) hinzugefügt und auf ein Unterverzeichnis (/xyz-beispiel/) von Domain ABC-BEISPIEL.de geschaltet. Der DOCUMENT_ROOT dafür müsste eigentlich wie folgt aussehen:

/home/strato/www/a/www.abc-beispiel.de/htdocs/xyz-beispiel

Tatsächlich wird der DOCUMENT_ROOT jedoch wie folgt angezeigt:

/home/strato/www/x/www.xyz-beispiel.de/htdocs

Damit könnte man ja noch leben, wenn der Pfad auf das oben beschriebene Unterverzeichnis linken würde. Tut er aber nicht. Stattdessen zeigt der Pfad auf das selbe Verzeichnis wie:

/home/strato/www/a/www.abc-beispiel.de/htdocs

Es scheint, als würde Strato als Wert für den DOCUMENT_ROOT immer den Pfad zum Hauptverzeichnis des Webspace-Accounts eintragen, unabhängig davon, auf welches (Unter-)Verzeichnis die Domain wirklich geschaltet ist. Damit ist die Umgebungsvariable DOCUMENT_ROOT praktisch nicht mehr zu gebrauchen. Man muss sich also den korrekten Pfad selbst zusammenbasteln.

Dabei spielt keine Rolle, welchen Pfad man benutzt. Es funktionieren

/home/strato/www/a/www.abc-beispiel.de/htdocs/xyz-beispiel

und

/home/strato/www/x/www.xyz-beispiel.de/htdocs/xyz-beispiel

Da fragt man sich echt, was das soll.

Wir wünschen allen Lesern und Kunden fröhliche und erholsame Feiertage.

Ein kurzer Tipp für alle, die E-Mails per Script versenden und neben der E-Mail-Adresse auch den Namen mit aufführen wollen. Eine falsche Formatierung des Absenders oder des Empfängers einer E-Mail kann zum Verlust derselben führen (und hat in der Vergangenheit auch schon dazu geführt). Besonders wichtig ist die korrekte Formatierung, wenn Werte aus einem Formular verwendet werden sollen. Sonderzeichen und Umlaute machen sonst Probleme.

"Vorname Nachname" <vorname.nachname@example.com>

Der Teil mit dem Namen gehört von Anführungsstrichen umschlossen und die E-Mail-Adresse gehört in spitze Klammern.

I love your Tell A Friend Script, it's the only one that allows full customization, and is well written - thanks!

Gern geschehen. :-)

Was macht man, wenn ein Script offensichtlich nicht installiert wurde und trotzdem funktioniert? Einen Exorzisten rufen?

Eine Kundin ließ uns wissen, dass das Captcha-Bild in ihrem Kommentar-Script nicht angezeigt wurde. Viele Möglichkeiten gibt es da nicht; das wird einfach, dachten wir uns.

Beim Aufruf der Seite wurde zwar das Kommentarformular und auch die Smiley-Bilder korrekt angezeigt, das Captcha-Bild jedoch nicht. Alles, wie von der Kundin geschildert. Meistens liegt das Problem an falschen Verzeichnisrechten oder der fehlenden Font-Datei, aber das Verzeichnis war schreibbar und auch die Font-Datei war vorhanden.

Warfen wir also einen Blick auf den Admin-Bereich. Da erwartete uns allerdings das Installationsformular (MySQL-Daten etc.), ein Zeichen dafür, dass das Script noch gar nicht installiert ist. Ebenso fehlte die dbconfig.php mit den MySQL-Zugangsdaten.

Das Script war offensichtlich noch nicht installiert und trotzdem wurde das Kommentarformular angezeigt. Wie konnte das sein? Nach einigem Probieren und Suchen fiel der Blick auf die Datei include.php, welche während der Installation des Comment Scripts automatisch erstellt wird. Die Datei enthält die absoluten Server-Pfad zum Script und bindet das Script in jede beliebige Seite ein. Die Frage war: wo kommt die Datei her, wenn das Script noch gar nicht installiert ist?

Nach dem Vergleichen des Pfades in der include.php mit dem tatsächlichen Server-Pfad lichtete sich der Nebel. Die Erklärung war dann auch relativ einfach und wenig mystisch. Die Kundin hatte Script unter Domain A installiert und zum Laufen gebracht. Später hat sie dann alle Script-Dateien in das Verzeichnis für Domain B auf demselben Server kopiert. Inklusive der include.php. Die enthielt jedoch den Server-Pfad zum Script auf Domain A. Damit wurde das funktionierende Script von Domain A bei Domain B eingebunden. Wäre das Captcha-Bild nicht gewesen, hätte das sogar funktioniert.

Das Rätsel ist also gelöst. Wie man sieht, benötigt es nicht besonders viel, um sich selbst zu überlisten. ;-)

Schreibt ein Kunde über unser Kommentar-Script:

This script is so robust! I've been using it for a while now [...] and the thing somehow filters all the spammers out and leaves good comments in. Although at first I didn't really pay attention but now that I think of it I am really really impressed. Both front end and back end are easy to use and make sense. I thought it would be a good idea to share my opinion with you and encourage more great applications like this!

Das freut den schwer schuftenden Script-Coder. :-)

Double Opt-in kennt jeder. Zur Bestätigung, dass die angegebene E-Mail-Adresse korrekt ist und tatsächlich existiert, muss man auf E-Mails antworten oder auf Links klicken. Einige Anbieter machen es, um einen "sauberen" Bestand an E-Mail-Adressen in der Datenbank zu haben, für andere ist es rechtlich relevant, wie zum Beispiel für Newsletter-Versender in Deutschland.

Double Opt-in wird aber auch zur Spam-Abwehr genutzt. Schreibt man jemandem eine ganz normale E-Mail, kann es passieren, dass man auf eine automatisch generierte E-Mail antworten oder einen Link in einer E-Mail anklicken muss. Andernfalls wird die eigene E-Mail gar nicht zugestellt. Es gibt dafür Anwendungen, die man sich auf dem eigenen Server installieren kann oder man nutzt einen entsprechenden Anbieter, der gegen Gebühr einen solchen Dienst anbietet.

Ob das jedoch wirklich eine gute Idee ist, scheint fraglich. Was ist, wenn diese automatisch generierte E-Mail auf der Strecke bleibt, weil sie im Spam-Ordner verschwindet oder weil man Sie schlicht übersieht oder nicht für wichtig hält und löscht? Der angefragten Firma könnte so ein Auftrag verloren gehen.

Wir kontaktierten kürzlich Moxiecode, den Hersteller von TinyMCE, einem WYSIWYG-Editor für Web-Anwendungen. Es ging um das kommerzielle Plugin MCImageManager und die Lizenzierung desselben für die Auslieferung zusammen mit unserem News Script.

Auf unsere Anfrage hin erhielten wir eine automatisch generierte E-Mail, die uns um Bestätigung bat. Durch den nicht gerade wenigen E-Mail-Verkehr mit unseren Script-Kunden haben wir häufiger mit dieser Art von E-Mail-Bestätigung zu tun. Andernfalls hätte die E-Mail zwischen all den Spam-E-Mails glatt übersehen werden können. Der Betreff sagt zwar eigentlich deutlich "Please confirm", aber Spammer schreiben alles mögliche in den Betreff hinein. Hätten wir also unsere E-Mail-Adresse nicht bestätigt, hätten wir auch niemals eine Antwort von Moxiecode bekommen.

Ist das nun im Sinne des Erfinders? Kann es ein Unternehmen tatsächlich riskieren, auf diese Art potentielle Kunden zu verlieren? Dass die beschriebene Methode der E-Mail-Address-Bestätigung zu 100% funktioniert, können nur wahre Optimisten glauben. Und so schlimm ist das mit dem Spam nun auch wieder nicht, dass man den Kunden noch über extra Hürden springen lassen muss. Es gibt genug andere Hilfsmittel, um die Spam-Flut einzudämmen.