ScriptBlogger

Ein Kunde des Wegwerf-E-Mail-Scripts meldete sich am 8. Januar kurz nach 21 Uhr im Support-Forum und schilderte sein Problem. Da wir nicht gleich am nächsten Tag reagiert haben, schrieb der Kunde eine E-Mail (so gegen 19 Uhr, Freitagabend).

Die E-Mail enthielt angeblich URL und Zugangsdaten zum Script. Beim Aufruf der URL war aber vom Script weit und breit keine Spur, was auch der Kunde auf Nachfrage bestätigte:

I was uploading files when you tested it I guess.

Das Ganze spielte sich zwischen 19 Uhr und 23 Uhr ab. Feierabend war eigentlich schon längst vorbei.

Zusätzlich zu der E-Mail hatte der Kunde übrigens auch im Support-Forum eine Nachricht geschrieben und eine Abstimmung gestartet:

How Quickly Do You Get A Support Request Answered?

[ ] Within 24 hours
[ ] Within 48 hours
[ ] Never
[ ] Never and forced to ask for refund

Bisher musste allerdings noch niemand eine Rückerstattung erzwingen. Entweder wir haben das Problem gelöst oder haben freiwillig das Geld zurückerstattet. Das ist nämlich Teil der bedingungslosen Geld-Zurück-Garantie, die auch im Forum an prominenter Stelle veröffentlicht ist.

Am 10 Januar (Samstag) kam dann um 4 Uhr morgens folgende E-Mail:

I have messed around with this script enough now. I guess that it must just be buggy. I would like a full refund asap.

Mit der Rückerstattung können wir leben. $29 sind nicht die Welt und es ist ja nicht so, als hätten wir das Geld schon auf den Kopf gehauen. Und dass wir die erste Anfrage übersehen haben ist natürlich blöd und dafür haben wir uns auch bei dem Kunden entschuldigt. Auf die zweite Anfrage, die nach Feierabend kam, haben wir aber sofort reagiert. Dass wir die Sache dann aber erst am nächsten Werktag weiter bearbeiten, kann uns niemand krumm nehmen. Wir bieten keinen 24-Stunden- und auch keinen Wochenend-Support an und versprechen das auch nicht. Etwas mehr Geduld wäre nett gewesen.

Unfair ist es allerdings zu behaupten, das Script wäre fehlerhaft (buggy), ohne uns die Chance zu geben, das Problem genauer anzusehen und gegebenenfalls zu beheben.

Das alles haben wir dem Kunden geschildert und natürlich auch die Rückerstattung veranlasst.

Wenig später kam dann folgende E-Mail:

Betreff: Order #999999999 Please Do Not Refund

I had my webhost have a look at the script and he repaired it. It had somthing to do with the way my email client handled new emails. The script is working perfectly.

Und im Forum schrieb der Kunde:

Betreff: All is forgiven, I apologize

The script is working perfectly, the problem was that my email was handled improperly by my email client. This was my fault, I wasn't knowledgable to figure this out. My friend found it. Thanks for looking Ralf. I do not want a refund

BTW - The script is great value for money and, if configured correctly by the installer (m fault) does just what it says it does on the packet

:-O

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

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.

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. ;-)

Dass Benutzereingaben kontrolliert und gefiltert werden müssen ist nicht neu. Machen wir bei allen unseren Scripten so. Meistens werden die Daten bei der Ausgabe an den Browser mit Hilfe von htmlentities() "gesichert". Alles, was möglich ist, wird dabei in HTML-Entities umgewandelt. > wird zu >, " wird zu ", und so weiter.

Als wir das Kommentar-Script seinerzeit entwickelten, haben wir die Umwandlung an den Anfang gesetzt - die Daten kamen so schon konvertiert in der Datenbank an. Irgendwann zwischen damals und heute haben wir htmlentities() durch strip_tags() ausgetauscht. Warum, weiß keiner mehr so genau. Normalerweise verwenden wir eine Kombination aus beiden Funktionen, um ganz sicher zu gehen.

strip_tags() allein zu verwenden, sollte sich als großer Fehler herausstellen. strip_tags() entfernt, wie der Name schon sagt, HTML-Tags und auch PHP-Tags. Alles andere - JavaScript-Code oder CSS-Styles zum Beispiel - bleibt bestehen. Resultat war, dass Nutzer sich bei uns meldeten. Hacker hätten Code eingeschleust und die gesamte Seite zu einem Link gemacht. Über den Admin-Bereich konnte der Kommentar noch nicht einmal gelöscht werden, da das Script gar nicht mehr auf die anderen Links reagierte.

Das Update und Veröffentlichung im Forum war schnell erledigt. Schließlich haben wir ja schon Erfahrung damit. ;-)

Manche Anfragen sind wirklich rätselhaft. Unsere Website ist online. Die Online-Demos funktionieren. Die Scripte lassen sich herunterladen. Die Links zum Bestellformular sind aktiv. Und auch im Support-Forum sind frische Antworten. Und trotzdem kam da letztens die Frage:

[...] are you still selling? I just don;t want to buy something no longer available.

Hm.

Wer ein Weblog oder Diskussionsforum betreibt weiß, wie schwierig es zuweilen ist, die Besucher dazu zu bringen, Kommentare zu hinterlassen oder Beiträge zu schreiben. Das Internet ist gespickt mit leeren Foren und unkommentierten Blogs.

Nicht anders ergeht es auch Seiten, die unser Comment Script einsetzen. Die Technik ist zwar dar und funktioniert auch, nur nutzen tut sie niemand. Deswegen lassen wir folgende Rückmeldung eines unserer Nutzer unkommentiert stehen. Als Hoffnungsmacher für alle anderen. ;-)

Since converting my site into Drupal or Wordpress would have caused many (mostly SEO) problems, I purchased your comment script in March and I am very satisfied with it. I haven't experienced any bug at all (maybe one: content blocker doesn't always work well). I have now 2000+ comments on 100+ "static" pages without any problem.

Here you can see a page with almost 200 comments if you are interested just to know I told the truth. :)

http://utazas-nyaralas.info/spanyolorszag/barcelona.html

Auf IncognitoMail setzen wir unser Wegwerf-E-Mail-Script ein - als Ausstellungsraum sozusagen. Wir würden IncognitoMail als ganz nützlich bezeichnen. Funktional. Mehr allerdings auch nicht.

Letztens sind wir über eine Pressemeldung einer unserer Kunden gestolpert. Die Überschrift lautete wie folgt (Domain geändert):

Example.com is Helping to Stop Email Spam – and Offering a Chance to Win a Pair of Mp3 Players

Soweit so unspektakulär.

Allerdings bezeichnete man sich im Verlauf der Pressemeldung ganz selbstbewusst als "... the Internet’s Premier Spam Fighting, Free Temporary Email Service ..." und "... the web’s most versatile Spam Stopping Disposable Email Address Service ...".

Dass unser Script gut ist, wussten wir ja. Aber, dass es so gut ist... ;-)

Wenn Scripte zu Spam-Schleudern werden, ist das alles andere als lustig. Ab und zu kommen Anfragen, ob diese Gefahr bei unseren Scripten besteht. Kürzlich kam ein konkreter Hinweis, dass angeblich zwei unserer Scripte Spam versenden. Das Abstimmungs-Script und das Kommentar-Script.

Zum Glück ist das beim Voting Script gänzlich unmöglich - es fehlt schlicht eine Mail-Funktion. Beim Comment Script gibt es für den Admin die Möglichkeit, sich über neue Kommentare per E-Mail informieren zu lassen. Da allerdings Daten aus dem Formular ausschließlich im Body der E-Mail landen, dürfte es für einen Angreifer nur schwer möglich sein, weitere Empfänger in den Header der E-Mail zu schleusen.

Der Nutzer hatte den Header der Spam-E-Mail im Forum veröffentlicht und darin lies sich folgende Zeile finden:

X-PHP-Script: example.com/example/general.php

Spätestens hier war Entwarnung angesagt. In keinem der beiden Scripte ist eine Datei namens general.php enthalten. :-P

Am Anfang der Woche haben wir eine neue Version des Schedule Organizer veröffentlicht. Das Update enthält eine Menge neuer Funktion, die von den Anwendern schon lange gewünscht wurden.

So ist es nun möglich, standardmäßig alle Termine zu blockieren und nur ausgesuchte Zeiten manuell freizugeben. Und falls diese Freigaben allzu spärlich ausfallen, gibt es einen Button, der den Anwender zum jeweils nächsten offenen Termin führt.

Das Script kann nun mit Zeitzonen umgehen. Die Anwender legen bei ihrer Registrierung ihre Zeitzone fest (kann später noch geändert werden) und das Script zeigt dann alle Uhrzeiten entsprechend den Zeitzoneneinstellungen an. Sehr hilfreich ist diese Funktion für Unternehmen, die Europa- oder Weltweit agieren. Die Funktion verlangt allerdings nach PHP 5.

Die Registrierungsfunktion ist nun vollwertig inklusive Aktivierung des Benutzerkontos. Außerdem lässt sich einstellen, ob Administrator, Operator, Nutzer oder alle bei Registrierung eine Benachrichtigungs-E-Mail bekommen.

Optional kann der Admin jetzt Links zum Script generieren, um den Anwender direkt zu einer bestimmten Woche, einem ausgewählten Reservierungsgrund, Terminbereich oder direkt zum Formular zu leiten. Diese Links können dann auf der Website oder in E-Mails platziert werden.

Im Admin-Bereich kann eine Termin-ID angezeigt werden (inklusive Suchfeld in der Terminliste).

Wenn ein Termin mehrmals reservierbar ist, wird nun farblich gekennzeichnet, wenn bereits Termine gebucht wurden. Dadurch sieht der Anwender, ob für eine bestimmte Uhrzeit bereits Termine gebucht wurden.

Das Script besitzt jetzt eine erneuerte Update-Routine. Die erkennt automatisch, ob der Betreiber die Script-Dateien aktualisiert hat und zeigt ein Update-Formular an. Nachdem der Betreiber die MySQL-Zugangsdaten eingegeben hat, aktualisiert das Script die Datenbanktabellen. Sobald das geschehen ist, hat der Admin wieder Zugang zum Admin-Bereich.

Die neue Version verfügt auch über einen Wartungsmodus, der im Admin-Bereich eingeschaltet werden kann. Dabei wird die Benutzeroberfläche abgeschaltet, damit der Admin eine neue Version des Scripts zum Server hochgeladen und installieren oder andere Einstellungen vornehmen kann, ohne dass es auf Anwenderseite zu Komplikationen oder Fehlermeldungen kommt.

Administratoren können jetzt entscheiden, ob Sie Termine löschen oder lediglich absagen. Im letzteren Fall bleiben die Termine erhalten und erschienen durchgestrichen in der Terminliste. Bisher war nur jeweils eine der beiden Optionen möglich.

In der Vergangenheit kam es ab und zu mal vor, dass ein Admin sich selbst ausgesperrt hat. Deshalb wird vor dem Löschen eines Benutzers mit Admin-Rechten deutlicher als bisher gewarnt.

Das Benutzeroberfläche gibt jetzt valides XHTML aus.

Das Script ist jetzt wieder abwärtskompatibel zu PHP 4 und wird es auch zukünftig bleiben. Einige optionale Funktionen wie Zeitzonen funktionieren dann allerdings nicht.

Und zu guter Letzt eine etwas exotische Funktion. Administratoren können Dateien hochladen und diese einem Benutzer oder Termin zuordnen. Denkbar wäre der Einsatz, um Patienten auf diesem Wege das Ergebnis von Tests oder Untersuchungen zukommen zu lassen.

Weiterführende Informationen  zum Schedule Organizer.

Ein Kunde unseres Kurz-URL-Scripts schrieb uns, dass sein Script einen Server-Fehler verursacht. Auf den ersten Blick schien jedoch alles zu funktionieren. Testweise "asdfasdf" in das URL-Feld des Scripts eingegeben und auch korrekterweise den Hinweis zum fehlerhaften URL-Syntax erhalten. Beim Eingeben einer korrekten URL in das Formular des Scripts meldete Apache allerdings einen Fehler.

Hm. Hin und her probiert und nach einer Weile ließ sich ein gewisses Muster erkennen. Der Server ließ es generell nicht zu, dass "http://" per POST oder GET an den Server übertragen wurde. Wir haben das mit einem einfachen Test-Script bestätigen können. Parameter wie ftp:// und https:// funktionierten interessanterweise.

Antwort vom Kunden:

It was due to the mod_Security rule set on server.

Ah ja.

Das Einbinden des Comment Scripts ist mit etwas Handarbeit verbunden. Grundkenntnisse in HTML und PHP vereinfachen und beschleunigen die Installation. Für alle weniger Erfahrenen hat ein Nutzer des Scripts ein Anleitungs-Video erstellt.

Mal sehen, ob es sich positiv (= verringernd) auf die Zahl Support-Anfragen auswirkt. B-)

Vor kurzem im Support-Forum aufgetaucht:

I have been using the short URL script for about two months on many posts. It has to be up there with some of the best systems I have encountered in several years. It works flawlessly, and of course, is very fast compared to the "Free Short URL Systems" on the internet. I am now master of of my URL's.

It is perfect.

:-)

Ein Nutzer unseres Gästebuch-Scripts erhielt eine erstaunliche E-Mail von seinem Webspace-Provider. Dieser schrieb ihm, dass die Datei sign.php des Gästebuch-Scripts Phishing-Material wäre:

We have received notification of phishing material in your account. Phishing files are usually placed through some type of exploit of out dated code, weak file and folder permissions. You must agree to remove this content and update any software that has resulted in security holes. To protect your account from further action you must agree to our request for compliance. Please respond to this message stating your intent to do so.

[...]

Failure to respond to this message within 72 hours will result in the suspension of the affected domain with us until such a time as this matter is resolved.

File path:

http://www.example.com/guestbook/sign.php*

Das ist ein ziemlich harter Ton, den der Provider dort anschlägt. Der Kunde bekommt nicht mal ansatzweise die Möglichkeit, eine Erklärung abzugeben oder die Ungefährlichkeit des Scripts zu versichern.

Das Script wird von Webmastern seit Jahren ohne Probleme auf unzähligen Servern installiert und läuft auf vielen auch heute noch. Erstaunlich ist, dass jetzt plötzlich jemand denkt, dass Script könnte für Phishing missbraucht werden. Man möchte meinen, dass bei über tausend Downloads jeden Monat irgendjemandem mal etwas aufgefallen wäre.

Eine Suche nach phishing "sign.php" ergab übrigens, dass es andere Scripte mit dem Namen sign.php gibt, die durch Sicherheitslücken für Phishing-Zwecke missbraucht werden können. Aber keine dieser Meldungen bezieht sich auf unser Gästebuch-Script.

Als Provider trotzdem gleich alle Scripte gleichen Namens von den eigenen Servern zu verbannen klingt nach Sippenhaftung. Oder Paranoia.

*) URL geändert