ScriptBlogger

Tschuldigung an alle, die den Feed dieses Blogs abonniert haben. Nachdem ein Bugfix die URLs korrigiert hat, wurden die Beiträge der letzten Tage bei einigen Feed-Readern erneut angezeigt. Die Änderung ist permanent. Es sollte also in Zukunft alles glatt gehen. Wir danken für Ihr Verständnis. ;-)

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

Wer seinen Server mit Plesk verwaltet, kann oder will den Server nicht per Kommandozeile administrieren.

Dieser Umstand scheint jedoch für die Entwickler von Plesk eine Neuheit darzustellen. Obwohl PHP 5 schon seit mehreren Jahren verfügbar ist, bietet die Plesk-Oberfläche keine Möglichkeit von PHP 4 auf PHP 5 zu aktualisieren. Von einem Parallelbetrieb beider Versionen ganz zu schweigen.

Stattdessen muss sich der Anwender mit yast, apt-get etc. herumplagen. Die Entwickler von Plesk sollten mal einen Blick auf die Verwaltungsoberfläche der Server von Domainfactory werfen. Dort stehen PHP 4 und PHP 5 jeweils in mehreren Versionen zur Verfügung.

Man kann offensichtlich nicht alles haben.

Microsoft spart wo es kann und verzichtet im Windows IIS unter PHP auf die Umgebungsvariable REQUEST_URI. Hier eine Lösung für das Problem:

<?php

/**
 * Request URI
 */
function my_request_uri()
{
    if (isset($_SERVER['REQUEST_URI'])
            and $_SERVER['REQUEST_URI'] != '') {
        return $_SERVER['REQUEST_URI'];
    }

    
    $path = '';
    if (isset($_SERVER['PATH_INFO'])
            and $_SERVER['PATH_INFO'] != '') {
        $path = $_SERVER['PATH_INFO'];
    }
    
    $query = '';
    if (isset($_SERVER['QUERY_STRING'])
            and $_SERVER['QUERY_STRING'] != '') {
        $query = '?' . $_SERVER['QUERY_STRING'];
    }
    
    if (isset($_SERVER['SCRIPT_NAME'])
            and $_SERVER['SCRIPT_NAME'] != '') {           
        return $_SERVER['SCRIPT_NAME'] . $path . $query;
    }
    
    if (isset($_SERVER['PHP_SELF'])
            and $_SERVER['PHP_SELF'] != '') {
        return $_SERVER['PHP_SELF'] . $query;
    }
    
    if (isset($_SERVER['SCRIPT_FILENAME'])
            and $_SERVER['SCRIPT_FILENAME'] != ''
            and isset($_SERVER['DOCUMENT_ROOT'])) {
        return str_replace($_SERVER['DOCUMENT_ROOT'], '', $_SERVER['SCRIPT_FILENAME']) . $path . $query;
    }
    
    return false;
}

if ($requestURI = my_request_uri()) {
    echo $requestURI;
}

?>

Beim Aufruf des Scripts unter http://www.example.com/test.php/my/path?test=123 würde folgendes ausgegeben:

/test.php/my/path?test=123 

Bei Open Source entwickeln wenige zum Nutzen vieler. Wir wenden ein ähnliches Konzept oft bei der Finanzierung von neuen Funktionen für unsere Scripte an. Sogar ganz neue Scripte sind dadurch entstanden. Der Link Manager zum Beispiel.

Wenn Kunden oder potentielle Kunden nach einer bestimmten Funktionalität fragen, erhalten sie ein Angebot. Dieses Angebot enthält den Preis für die Erstellung der Funktion zur exklusiven Nutzung. Soweit so unpsektakulär. Gleichzeitig bieten wir jedoch auch die Möglichkeit eines Preisnachlasses für den Fall an, dass wir die neue Funktion in die offizielle Version des jeweiligen Scripts übernehmen dürfen.

Neben dem bereits erwähnten Kostenvorteil ergibt sich für den Kunden folgender Nutzen:

• Wir pflegen die Funktion im Zuge von normalen Updates weiter.
• Durch die breitere Nutzung fallen Fehler eher auf und werden deshalb auch eher behoben.
• Bei allgemeinem Bedarf kann die Funktionalität sogar noch erweitert werden.
• Der Kunde hat immer eine offizielle Version. Im Falle neuer Versionen muss die Extraanfertigung nicht jedes Mal wieder nachgerüstet werden.

Bis jetzt konnte sich noch kein Kunde diesen Argumenten entziehen. :-)

Vor einer Weile erschien ein Artikel von Jane Copland über Nutzen und Fallstricke von Kurz-URL-Diensten.

Eine Option, die in dem Artikel nicht zur Sprache kommt, ist die Installation eines solchen Scripts auf dem eigenen Server.

Nutzen:

• Man kann (s)eine eigene Domain nutzen
• Man kann das Aussehen des Dienstes den Rest seiner Website angleichen
• Man muss nicht fürchten, dass der Dienst irgendwann eingestellt wird

Fallstrick:

• Die URL ist möglicherweise länger als üblich. Solange diese aber in eine Zeile einer E-Mail passt, sollte einem das keine schlaflosen Nächte bereiten.

Nachdem es hier in letzter Zeit überwiegend positives Feedback von Kunden zu lesen gab, ist's mal wieder Zeit für ausgleichende Gerechtigkeit.

Letztes Jahr im Oktober hatte ein Kunde unser Form Mail Script gekauft. Nach anfänglichen Schwierigkeiten lief das Script dann auch. Abschließend hatte der Kunde noch den Wunsch, dass die E-Mails jeweils an mehrere Empfänger gesendet werden sollen. Wie genau er sich das vorstellte, war mir jedoch nicht ganz klar. Und irgendwie war es auch nicht möglich, mal einen Blick auf die Templates (HTML und Mail) zu werfen.

Nach einigem Hin und Her mit Tipps und Rückfragen waren mittlerweile zwei Monate ins Land gegangen. Nach einer solchen Zeitspanne besteht immer die Gefahr, dass entweder der Kunde die Geduld verliert oder dass die Angelegenheit hier untergeht.

Am 3. Januar schrieb der Kunde seine vorerst letzte E-Mail in der er wissen wollte, mit welchem Zeichen er am besten mehrere Empfänger im Bcc-Header voneinander trennt. Die richtige Antwort wäre das Komma gewesen. Leider habe ich seine E-Mail nie beantwortet.

Dass das keine gute "Idee" war, sollte sich jetzt im September, neun Monate später herausstellen.

Betreff: 10 Months and still trying to get some support

This is really becoming a pain in my ass. I PAID for a product (invoice attached) that I EXPECT to work like it says it should. I can’t even register for your damn forums as when I click the “I agree to the terms button” all it does is refresh the page. It won’t even allow me in to register.

Now, here is my problem again.

I need the freaking form to mail to multiple people, it don’t. Why and how do I fix it.

Ooops.

Es wäre allerdings ganz hilfreich gewesen, wenn der Kunde mal etwas früher nachgehakt hätte. Aber ich stehe dazu, dass die Schuld bei mir liegt und habe mich für den Fauxpas entschuldigt:

You're right. I should have answered your support questions a long while ago. It appears that your e-mail has been overlooked. There is no real excuse for that but I'm getting a lot of e-mails and I occasionally miss an e-mail.

Die Sache hat jedoch einen Haken. Ein rüder Ton mag vielleicht bei anderen ziehen, nicht aber bei mir. Deswegen enthielt meine E-Mail noch folgenden Zusatz:

Anyway, $19 might be a lot of money for some people, but it's not enough for me to read words like "ass" "damn" and "freaking" in an e-mail. Therefore, I'll go ahead and cancel your order and refund your money. There are plenty of other Form Mail Scripts so that you'll have something to fall back on.

Thanks anyway for considering my script in the first place.

Es trudelten hier dann noch eine Hand voll weiterer böser E-Mails ein.

Und was lernen wir aus dieser Geschichte? Leiste vernünftigen Support, sonst machen die Kunden Ärger. Was jetzt allerdings auch wirklich keine bahnbrechende Neuigkeit ist. ;-)

Mal sehen übrigens, ob der (Ex-)Kunde folgende Drohung wahr macht:

Believe me, I will now go out of my way to make posts and reviews on my sites, blogs, article directories and anywhere else that I can find to state what kind of crap you offer.

Einige unser Kurz-URL-Dienste hatten eine kleine Auffrischung der Optik verdient. Bis dato nutzten sie noch das Standard-Layout des Kurz-URL-Scripts. Die Sache war fix erledigt, das Ergebnis kann man gelten lassen und viel gekostet hat's auch nicht (iStockPhoto lässt grüßen).

FlatURL.com

TeenyWeenyURL.com

KleinerLink.de

Eine Support-Anfrage sollte idealerweise in einem freundlichen Ton geschrieben sein, ausführlich das Problem beschreiben und als Sahnehäubchen noch einen Link zum nicht funktionierenden Script beinhalten. Soweit so gut.

Ein Konzept, das an folgendem Fragesteller jedoch komplett verloren gegangen ist:

your programme has given me problems for the past one week. i really need to vote but its jamming. I cant vote for reasons i don't know so please fix this problem because I really need to vote urgently!!!!!!!!!!!!!!!!!!!

;-)

Vor einem Monat haben wir einen Konfigurator für unser Voting-Script online gestellt. Statt mit einer Konfigurationsdatei zu hantieren, kann der Anwender das Script bequem per Browser einstellen und im Anschluss die fertige Konfigurationsdatei herunterladen.

Allerdings scheinen wir damit ein Problem gelöst zu haben, dass eigentlich keines war. Von einer Hand voll Zugriffen abgesehen oxidiert das Tool ungenutzt vor sich hin. Gerade mal eine einzige "richtige" Konfiguration wurde damit vorgenommen.

$vote_title             = 'Presidential Elections';
$vote_text              = 'Who will win the Presidential Elections';

$vote_option[]          = 'Barack H. Obama';
$vote_option[]          = 'John S. McCain III';

B-)

Ab und an landen Besucher auf dieser Seite, die nach einem Script-Blogger für Mozilla (Firefox und Konsorten) suchen.  Was sie allerdings tatsächlich finden wollen ist ein Script-Blocker. Sehr löblich. Wir empfehlen NoScript:

NoScript - Allow active content to run only from sites you trust, and protect yourself against XSS attacks. 

Die Entwickler von NoScript sind recht aktiv. Ständig gibt's neue Updates. Kann man jedem nur raten.

Auf Grund eines Bugs in PHP 4, der von der PHP-Group verständlicherweise nicht mehr behoben wird, verlangt unser Schedule Organizer nach PHP 5. Zwar haben viele Webspace-Provider bestehende Webspace-Konten noch immer nicht von PHP 4 auf PHP 5 umgestellt, aber das war auch kaum zu erwarten. Umgestellt wird dann zumindest, wenn man den Provider darum bittet. Meistens jedenfalls.

Ein Kunde von uns sah sich allerdings mit folgender Antwort konfrontiert:

To parse php scripts in PHP5 please rename your PHP scripts to have a .php5 extension.

Eine völlig inakzeptable Antwort. Vor vier Jahren, als PHP 5 erst bei wenigen Webhoster parallel zu PHP 4 angeboten wurde, hätte man das vielleicht noch durchgehen lassen können. Und das obwohl es mit .htaccess einen weitaus besseren Weg gibt, .php-Dateien als PHP 5 parsen zu lassen.

Der Kunde hat sich dann nochmal an den Support des Webhosters gewandt und folgendes als Antwort bekommen:

Dear Customer,

The script that you have provided for a .htaccess file is written for the Apache mod_rewrite facility, this will not work correctly however as we do not run Apache on our hosting cluster instead we run Zeus on our hosting package which does not support mod_rewrite. Alternatively you can use rewrite.script which is Zeus's version of mod_rewrite however we cannot support the coding itself.

Ein Script "... written for the Apache mod_rewrite facility ..."? Was hat mod_rewrite mit PHP zu tun? Da fragt man sich, wie kompetent der Webhoster reagieren wird, wenn es mal ein ernsteres Problem gibt.

Wir haben uns dann nochmal reingehängt und versucht eine Lösung zu finden. Leider ohne Erfolg. Deswegen baten wir den Kunden, nochmal bei seinem Provider nachzufragen, ob sich PHP 5 wirklich nicht standardmäßig für den Webspace-Account einstellen ließe. Was wir uns da wieder gedacht haben ...

At this point in time we have to keep PHP 4 the default version due to our hosting being a shared environment. If we changed to PHP 5 as default on our servers it would be disastrous as thousands of our customers websites would go down. Some time in the near future we will look at moving over to PHP5 as default however for the time being you will need to rename all of your scripts to .php5 to parse them in PHP version 5.

Offensichtlich ein weiterer Webhoster, der jahrelang gepennt hat, statt sich vernünftig auf PHP 5 vorzubereiten. Es ist ja schließlich nicht so, als wenn PHP 5 über Nacht über das Internet hereingebrochen ist. :-O

.. ist für den anderen ein Server, der nicht wie gewünscht funktioniert.

Wir haben bei Host Europe einen virtuellen Server, der in den letzten Monaten anstandslos seinen Dienst verrichtete. Wenn mal etwas klemmte, war immer zu starker Traffic schuld.

Das letzte Mal allerdings ließ sich Traffic als Störfaktor¹ ausschließen. Die Symptome waren wie folgt:

HTTP: Die Seiten benötigten zum Teil mehrere Sekunden (5-10) zum Laden

FTP: Verbindung zum Server war anfangs nur sehr zäh, später gar nicht möglich

Plesk: Verbindung war sehr, sehr zäh

Mail: Funktionierte ohne Probleme

Ein Neustart des Systems hat die Probleme nur kurzfristig gelöst. Host Europe hat dann "[...] einige Optimierungen am Wirtssystem durchgeführt.", was aber auch nichts gebracht hat.

Nächste Antwort von Host Europe:

Leider lassen sich solche Geschwindigkeitsschwankungen bei geteilten Systemen wie dem VPS nicht generell vermeiden. [...]

Ausfall von FTP ist keine Geschwindigkeitsschwankung. Und Ladezeiten von Plesk und HTTP von über zwei bis drei Sekunden sind weder akzeptabel noch normal. Host Europe macht da seine Systeme schlechter als sie tatsächlich sind. Der Server lief in den letzten Monaten anstandslos.

Ein Neustart am nächsten Tag hat die Probleme zunächst gelöst. Wir werden sehen, wie lange das anhält.

Update: Es gibt Anzeichen, dass das Problem möglicherweise bei Kabel Deutschland lag. Unser Server bei Domainfactory machte plötzlich ebenfalls Zicken. Nach dem Wechsel auf die Telekom-Leitung hatte sich dass allerdings erledigt. Sorry hiermit an den Support von Host Europe. ;-) Das ändert jedoch nichts an der Tatsache, dass der Support von Host Europe ernsthaft der Meinung ist, dass man Ladezeiten von drei bis fünf Sekunden für eine Web-Seite in Kauf nehmen muss.

¹) Prinzipiell gesehen sind zuviele Besucher ein Luxusproblem. Man kann eigentlich nie genug Traffic haben. ;-)

Ein Nutzer unseres Datei-Download-Scripts liefert damit Filme aus. Die Dateien sind jeweils um die 10 GB groß und liegen deshalb auf einem extra Server mit günstigerer Bandbreite.

Der Nutzer äußerte nun den Wunsch, das Script auf dem Server mit der eigentlichen Website (Server A) zu installieren und auf die Filmdateien auf Server B zugreifen zu lassen. Er hätte gern alles unter einer einheitlichen Domain gehabt. Allerdings ist das Script dafür nicht ausgelegt, sondern kann nur Dateien ausliefern, auf die es über einen lokalen (Netzwerk-)Pfad zugreifen kann.

Für den Nutzer hat sich dieser Umstand jedoch als positiv herausgestellt, denn da gab es einen kleinen Denkfehler seinerseits. Wenn nämlich das Script auf Server A installiert ist und auf die Dateien auf Server B zugreift, werden die Dateien immer über Server A geschleust. Das Script liest dabei die gesamte Datei ein und gibt sie an den Browser aus. Und das kostet dann gleich zweimal Bandbreite - einmal auf Server B und einmal auf Server A. Das schien dann doch nicht so ganz im Sinne des Erfinders zu sein. Sah dann auch der Nutzer so:

Thanks a lot for your support! double bandwidth ..... grrhhhhh.nope!

Zumal man einfach eine Sub-Domain einrichten kann, welche dann auf Server B gerichtet ist.

Sofern das eigene Weblog über diese Fähigkeit verfügt, kann man Ping-Server per XML-RPC über neue Beiträge informieren. Motiviert durch eigenen Bedarf haben wir unsere Liste mal durch neue Dienste erweitert und durchgetestet. Dabei haben wir alles rausgeworfen, was nicht erreichbar und offensichtlich den Geist aufgegeben hat.

Tadaaaaa:

• http://rpc.blogrolling.com/pinger/
• http://rpc.technorati.com/rpc/ping
• http://rpc.weblogs.com/RPC2
• http://api.my.yahoo.com/RPC2
• http://services.newsgator.com/ngws/xmlrpcping.aspx
• http://api.moreover.com/RPC2
• http://www.blogpeople.net/servlet/weblogUpdates
• http://bblog.com/ping.php
• http://ping.feedburner.com/
• http://ping.syndic8.com/xmlrpc.php
• http://blogsearch.google.com/ping/RPC2    
  
• http://rpc.icerocket.com:10080/    
  
• http://rpc.pingomatic.com/
• http://xmlrpc.bloggernetz.de/RPC2
• http://bblog.com/ping.php
• http://blog.goo.ne.jp/XMLRPC
• http://api.my.yahoo.co.jp/RPC2
• http://xping.pubsub.com/ping/
• http://rpc.reader.livedoor.com/ping
• http://ping.wordblog.de/
• http://blogsearch.google.at/ping/RPC2
• http://ping.weblogalot.com/rpc.php
• http://ping.bloggers.jp/rpc/
• http://blogsearch.google.de/ping/RPC2
• http://ping.namaan.net/rpc
• http://rpc.technorati.jp/rpc/ping
• http://zhuaxia.com/rpc/server.php
• http://www.bloglines.com/ping
• http://rpc.bloggerei.de/ping/