ScriptBlogger

Nachdem unser Kurz-URL-Script schon mehrere Jahre auf dem Markt ist und noch nie durch Performance-Probleme aufgefallen ist, zickt jetzt ein Webspace-Provider herum.

This script will perform just fine when there is no load on the server, but at average load you script will run poorly.

Unser Kunde wies seinen Provider darauf hin, dass seine Website kaum Besucher hat und er es für unwahrscheinlich hält, dass das Script für die Probleme verantwortlich ist. Der Webhost legt dann mit folgender Erklärung nach:

The server load is not made up only upon your site alone, but there is many sites on the same server. Some receive more hits than others. Even though your site only may receive a few hits a day, other sites my get a 1000 hits or more. The server load is affected by all sites on the server. When the server is on a normal load amount, it seems your site gets slowed down because of the script.

Zur Erinnerung. Wir sprechen hier von einem Script mit zwei Datenbanktabellen. Eine davon mit höchstens ein paar Tausend Datensätzen, die andere mit rund 20. Beim Abruf einer URL wird per ID gesucht, für die ein Index existiert.

Unser Kunde hält die Aussagen der Webspace-Firma für fragwürdig:

There is simply as a condition that is not acceptable on any internet site. I don't believe for one moment that the short URL script is the cause of the slow loading at various times.
Further I will test the site with normal long URL's and see if there is any difference. I have used Hosts for too long to buy your explanation.

Yep, wir ebenso wenig. Es gibt allerdings einen Umstand, der dem Server tatsächlich zusetzen würde und bei unseren eigenen Seiten (flaturl.com, gentleurl.net) auch tatsächlich zu Problemen geführt hat. Wenn nämlich die URLs zu Bilddateien mit Hilfe des Schort URL Script gekürzt und dann in eine Seite eingebaut wurde. In der Vergangenheit wurden diese URLs in chinesischen Foren mit hohem Besucheraufkommen oder in den Kommentaren von MySpace-Profilen eingebaut wurden. Das bedeutet, dass bei jedem Aufruf der MySpace- oder Forums-Seite auch gleichzeitig ein Aufruf zu unserer Seite gemacht wurde. Bei mehreren Requests pro Sekunde über einen längeren Zeitraum fing der Server dann an zu ächzen. Seit wir aber entsprechende Seiten per .httaccess blockieren, ist auch das kein Problem mehr.

Bei unseren Seiten flaturl.com und gentleurl.net sind derzeit zusammen knapp 40.000 URLs in den Datenbanken. Seit Beginn wurden über 10. Mio Aufrufe gezählt und täglich kommen rund 3.000 dazu, mit Spitzen von 8.000 Aufrufen. Das sind sicherlich keine rekordverdächtigen Zahlen, aber genug um zu zeigen, dass eine normale Nutzung des Scripts nicht gleich den gesamten Server aus der Puste bringt.

Ich habe vorhin einem Kunden ein paar Fragen aus verschiedenen E-Mails zusammen in einer Nachricht beantwortet. Kam als Hinweis auf eine der Antworten:

This was not me asking this question [...]

Uups, aus der falschen E-Mail kopiert. Entweder werde ich alt oder ich bin urlaubsreif. ;-)

Aus einer Antwort im Support-Forum:

great script man! keep rocking the planet!

Aber sicher doch. :-)

Google hat eine Kundin von uns angeschrieben und sie um die Teilnahme an einer Umfrage bezüglich Adwords eingeladen. Als Dankeschön winkt ein Goole Strandball [sic!].

Nützlicher wäre ein Gutschein, also Bares, gewesen. Vielleicht lässt sich der Ball ja bei eBay verscherbeln. ;-)

Unser News Script ist gar nicht mal so schlecht. Verglichen mit Wordpress und Serendipity fehlen aber noch ein paar (OK, eine Menge) Funktionen. Einen Kunden von uns ficht das nicht an:

I have WP and I really don't care for them and to me your news script is a lot better than anything out there.

Vor einigen Wochen haben wir in dem Artikel "Digg und Reddit versus Yigg und Webnews" unseren Gedanken zum Thema News-Communities freien Lauf gelassen. Einfach nur meckern kann aber jeder und so haben wir die Ärmel hochgekrempelt und in die Tasten gehauen. Im März hat dann ausgebuddelt.de das Licht der Welt erblickt. Mittlerweile funktioniert alles reibungslos und die bislang angemeldeten Leute bewerten und kommentieren schon recht fleißig.

Ziel der Seite ist es, News abseits vom Mainstream zu präsentieren. Interessantes aus der Nachrichtenwelt ist auf jeden Fall willkommen, aber das tägliche Einerlei kann man sich auch über Google News besorgen. Willkommen auf ausgebuddelt.de sind Videos, Bilder, Blog-Artikel und alles was sonst noch gerade aktuell ist.

Wie genau die Seite funktioniert erklärt die Anleitung und über Neuerungen informiert ein eigener Blog. Außerdem gibt es ein Bookmarklet und einen Button zum Einbau in die eigene Website.

ausgebuddelt.de - News Community

MailWasher von FireTrust ist eines von den Programmen, die man nach einer Weile nicht mehr missen möchte. MailWasher hilft dabei, unerwünschte E-Mails gleich auf dem Server zu löschen. Anhand von eigenen und auch lernenden Filtern, externen Spam-Listen, White- und Black-Listen kann man eingehende E-Mails automatisch vorsortieren und muss am Ende nur noch wenige E-Mails manuell zum Löschen markieren.

Notwendig wurde das Programm, als hier über 4000 E-Mails am Tag eintrafen. Mittlerweile konnte das Server-seitig auf rund 400 E-Mails am Tag gedrückt werden. Immer noch genug, um den Einsatz von MailWasher zu rechtfertigen.

Es gibt eine kostenlose und eine kostenpflichtige Version, welche sich im Funktionsumfang unterscheiden. Die kostenlose Variante ist auf eine E-Mail-Adresse beschränkt und es fehlt der „Recycle-bin". Letzterer enthält alle gelöschten E-Mails als Sicherheitskopie, falls man sich mit dem Löschen geirrt hat.

Es hat sich herausgestellt, dass es entgegen früheren Erkenntnissen doch eine Sicherheitslücke in zweien unserer Scripte gab, die Cross Site Scripting erlaubte. Das Problem war $_SERVER['PHP_SELF'], das nicht genügend auf eingeschleusten JavaScript-Code geprüft worden war. Dadurch wäre es einem Angreifer zum Beispiel möglich, Zugriff auf die Session-Cookies eines Benutzers zu erlangen.

Betroffen hat es das Form Mail Script und das Voting Script. Für beide Scripte gab's natürlich sofort Updates und für den Hinweisgeber eine kostenlose Script-Lizenz.

Jedes Mal, wenn der Managed Server eines Kunden bei 1&1 abschmiert, stimmt die Zuordnung der Subdomain www. auf das ursprünglich zugewiesene Verzeichnis nicht mehr. Passiert ungefähr einmal jährlich. Diesmal wurde versprochen, das Problem ein für alle Mal zu beheben. Ah, ja. Möchte jemand 'ne Wette darauf abschließen? ;-)

Kleiner Tipp noch für alle, die ebenfalls einen Managed Server bei 1&1 haben: Sollte mal was sein, zuerst darum bitten, dass der Server komplett neu gestartet wird. Der Support von 1&1 neigt dazu, erst stundenlang an dem Teil herumzufummeln. Hat einem Kunden schonmal unnötig einen ganzen Tag gekostet. Dabei hatte sich anscheinend nur der MTA aufgehängt. Eine Sache, die in fünf Minuten erledigt gewesen wäre.

Dass Nutzer eine bestimmte Funktion im Script nicht finden können, ist Alltag. Dass der Entwickler die Funktion nicht findet, passiert eher selten. Und doch ist es geschehen, wie folgender Forums-Dialog beweist:

Nutzer 1: I can't seem to find the config section that makes filling in an email address compulsory.

Entwickler: You mean in the admin area?

Nutzer 1: For when making a booking or registering a user [...]

Nutzer 2: i cant remember for sure but im sure this is in one of the config files

Entwickler: The e-mail fields in the admin area are not required and there is no option to change that, I'm afraid.

Nutzer 1: How about for when a new user is registering an appointment?

Entwickler: In the user front end the e-mail field is compulsory. Only in the admin area it is not.

Nutzer 2: $configuration['customer_email_required'] = true; in core.inc.php

Entwickler: Are you sure?

Nutzer 2: no im not :-( it was there before though

Entwickler: I thought so, too, first but I couldn't find it. Weird.

Nutzer 1: Not finding it eigther

Es kann kein gutes Zeichen sein, wenn Entwickler und Nutzer davon überzeugt sind, dass es eine bestimmte Funktion gäbe, diese tatsächlich aber gar nicht da ist. Halluzinationen? Gespenster? Verhexte Scripte?

Die meisten Website-Betreiber möchten PHP-Session-IDs verstecken - meist vor Suchmaschinen. Das Anhängen der Session-ID an URLs und Formulare wird deshalb von vielen deaktiviert und man verlässt sich auf die Weitergabe der Session-ID per Cookie. Das ist auch kein Problem, solange der Besucher der Seite tatsächlich Cookies aktiviert hat.

Problematisch wird es, wenn ein PHP-Script per Server Side Includes (SSI) eingebunden ist. Dann nämlich ruft nicht der Browser die PHP-Datei auf, sondern der Server und dieser fügt dann die Ausgabe der PHP-Datei in die SSI-Datei. Resultat ist, dass der Cookie gar nicht beim Browser ankommt und Funktionen, die sich auf eine aktive Session verlassen, nicht funktionieren.

Ein ähnliches Problem gibt es mit Iframes. Je nach Einstellung lässt der Browser Cookies von Dritten nicht zu. Wenn zum Beispiel scriptblogger.de die Seite example.com per Iframe einbindet, kann es sein, dass der Cookie von example.com vom Browser abgewiesen wird. Auch hier muss man die Weitergabe der Session-ID per URL oder Formular (re-)aktivieren.

Was PHP-Scripte mit Kuchen zu tun haben? Frage eines Kunden im Support-Forum:

Exporting to multiple Google Calendars would be the icing on the cake as this can be configured for SMS alerting, etc.

Unsere Antwort:

No icing, I'm afraid. Just the bare cake. ;-)

Letztens im Forum:

I need my site to be PCI compliant. McAfee Secure (which used to be ScanAlert) is showing errors in index.php due to cross-site scripting.

PCI compliancy hat was mit Kreditkartendaten zu tun, die übers Web versendet werden.

Ich bin aus zwei Gründen extrem skeptisch. Erstens, ich traue automatischen Scannern nicht. Und zweitens, das Script wäre schon vor Ewigkeiten in Mailing-Listen wie Secunia oder Bugtraq erwähnt worden, gäbe es tatsächlich eine Sicherheitslücke.

Jeder kann es selbst ausprobieren. Keine der Fallbeispiele auf folgender Seite schlagen an:

http://ha.ckers.org/xss.html

Im Endeffekt ist es ganz einfach. Solange keine konkreten Hinweise kommen, können wir nichts tun. Mit vagen Aussagen kann man wenig anfangen. Sollte sich aber tatsächlich eine Sicherheitslücke finden, ist diese in Null Komma Nichts behoben. Aber bis dahin halten wir die Füße still und hoffen, dass andere Nutzer sich nicht verunsichern lassen.

Wenn ein Kunde Probleme mit seinem Script hat und die ersten ein oder zwei Tipps nicht helfen, gibt's nur eine Möglichkeit: FTP-Zugangsdaten anfordern. Das ist aber nicht immer möglich. Meist aus folgenden Gründen:

1. Der Server steht lokal beim Kunden und ist per Internet nicht zu erreichen.
2. Der Kunde testet das Script auf einem lokalen Rechner, bevor er es endgültig auf dem Server installiert.
3. Zugang zum Server ist an eine oder mehrere IP-Adressen gebunden.
4. Der Kunde möchte nicht, dass Dritte Zugang zum Server haben.
5. Der Auftraggeber des Kunden möchte nicht, dass Dritte Zugang zum Server haben, obwohl der Kunde die Daten eigentlich gern herausrücken würde.

Im Fall 1 kann man sich schon mal auf einen Schwung E-Mails einstellen, die hin und her gehen werden. Kein Argument der Welt wird das ändern können.

Im zweiten Fall hat es bisher immer geholfen, den Kunden zu bitten, das Script direkt auf dem Server zu installieren. Im Großteil der Fälle hat sich damit auch gleich das Problem gelöst. Wir haben es schon oft erlebt, dass irgendetwas mit dem lokalen System des Kunden nicht funktionierte.

Im Fall 3 kann man Glück haben und der Kunde gibt die IP, die man gerade benutzt, für den Zugriff frei. Blöd ist allerdings, wenn sich der Support über mehrere Tage zieht und der Provider einem täglich eine neue IP-Adresse zuweist.

Für die Fälle 4 und 5 gibt es einige Argumente, die fast immer ziehen.

• Man versichert, dass der Zugang zu Kunden-Servern absolute Routine ist und dass man das schon bei Hunderten Kunden gemacht hat.
• Der Kunde soll den Zugang auf das Verzeichnis beschränken, in dem das Script liegt.
• Ohne Zugang wird es Tage dauern, bis das Problem behoben ist. Instruktionen und aktualisierte Dateien per E-Mail hin- und herzusenden ist zu zeitraubend.
• Support dieser Art muss man, auf Grund des Zeitaufwands, extra in Rechnung stellen.

Vermutlich ist es der letzte Punkt, der den Ausschlag gibt. Schade eigentlich, da wir ungern mit der Kostenkeule wedeln. Support ist eigentlich im Script-Preis enthalten und die Kunden sollen sich nicht abgezockt fühlen.

Ein Script von uns funktionierte auf dem Server des Kunden nicht ganz korrekt. Es sollte E-Mails versenden, tat es aber nicht. Ein kurzer Blick in die Kristallkugel ergab, das womöglich der safe_mode daran schuld ist. Die Kristallkugel sollte recht behalten.

Seit einer Weile schreiben einige Webspace-Provider vor, dass man bei Scripten die Return-path-Kopfzeile angibt. Das macht man mit Hilfe des fünften Parameters der Funktion mail(). Ist auch nicht weiter wild. Unsere Scripte können damit umgehen.

mail(
    'empfaenger@example.com',
    'Betreff',
    'Nachricht',    
    'From: absender@example.com',
    '-fwebmaster@example.com'
    );

Ist aber der safe_mode aktiviert, ist der fünfte Parameter nicht erlaubt. Ergo werden auch keine E-Mails versendet. Das ist kein Problem, denn das Script verzichtet im safe_mode automatisch auf den fünften Parameter.

Leider hatte der Kunde noch eine Version des Scripts, in der diese Funktion fehlte. Man hätte jetzt ein Update machen können, aber der Kunde entschied kurzerhand, den safe_mode abzuschalten. Um so besser. Leider haben nur die wenigsten Anwender diese Möglichkeit.

Jetzt fing aber die Sache erst an, spannend zu werden. Den Pfad der php.ini hat der Kunde noch relativ zügig herausgefunden. Trotz Änderung und Neustart des Apache blieb jedoch der safe_mode eingeschaltet. Wenig hilfreich war auch die Tatsache, dass es mehrere php.ini an verschiedenen Orten auf dem Server gab.

Schlussendlich ließ sich die Einstellung in der Konfiguration der virtuellen Hosts finden:

/srv/www/vhosts/beispiel-domain/conf/httpd.include

Da wollte anscheinend jemand mit aller Macht sicherstellen, dass auf dem Server der safe_mode aktiviert bleibt. :-P