ScriptBlogger

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.

An den Superglobals von PHP sollte man besser nicht herumfummeln. Stattdessen sollte man Kopien von $_POST, $_GET und $_COOKIE erstellen und diese dann ändern. Wer das bisher noch nicht beherzigt hat, dem sei folgendes Beispiel vor Augen geführt.

Angenommen wir möchten uns nicht darauf verlassen, dass magic_quotes_gpc in der php.ini aktiviert ist. Stattdessen wollen wir manuell sicherstellen, dass alle Elemente in den Arrays mit addslashes() behandelt werden. Dabei hilft folgende Funktion, die wir per array_walk() aufrufen. Die Funktion hangelt sich rekursiv durch ein Array und wendet addslashes() auf jedes Element in diesem Array an.

<?php 

function escape_input(&$value)
{
    if (is_array($value)) {
        array_walk($value, 'escape_input');
        return;
    }

    if (ini_get('magic_quotes_gpc')) {
        $value = stripslashes($value);
    }
    $value = addslashes($value);
}

Nehmen wir weiter an, der Wert von magic_quotes_gpc in der php.ini ist false. Eingaben, die beispielsweise ein Hochkomma oder Anführungsstriche beinhalteten, werden in diesem Fall nicht automatisch mit einem Backslash versehen (escaped). Würden wir jetzt obige Funktion direkt auf $_POST anwenden, veränderten wir diese Superglobale, ohne dass andere Komponenten dies mitbekommen.

Die Pear-Klasse QuickForm ist so ein nichtsahnender Kandidat. Bevor QuickForm POST-Daten zurück in die Formularfelder schreibt, überprüft die Klasse, ob magic_quotes_gpc aktiviert ist. Ist dies der Fall, werden eventuell vorhandene Backslashes vorher entfernt, andernfalls werden die Daten unverändert übernommen. In einer Situation, in der magic_quotes_gpc abgeschaltet ist und wir $_POST nachträglich mit Backslashes versehen haben, tauchen diese Backslashes in den Formularfeldern auf.

Umgehen lässt sich dieses Problem nur, indem wir Änderungen ausschließlich an Kopien von $_POST etc. ausführen und diese Kopien in unseren Scripten verwenden.

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 &gt;, " wird zu &quot;, 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. ;-)

Es ist zwar etwas kurzfristig, aber vielleicht kommt's ja doch noch rechtzeitig für den einen oder anderen. Heute (18. November) Abend um 20 Uhr findet in Lehmanns Buchhandlung im Hamburg der Vortrag "PHP-Applikationsentwicklung mit dem Zend Framework" statt.

Im Rahmen des Vortrags stellt Jan Burkl von Zend Technologies die PHP-Applikationsentwicklung mit Zend Framework (und Zend Studio for Eclipse) vor - anhand der Entwicklung einer Beispielapplikation mit:

• Formulare mit Dojo-Unterstützung
• Authentifizierung und Authorisierung
• Datenbankzugriff
• Layout Gestaltung

Vielleicht sieht man sich ja.

Bei einem Kundenprojekt empfängt und verarbeitet die Anwendung E-Mails mit Hilfe der IMAP-Funktionen von PHP. Dabei wird auch der Zeichensatz ausgelesen und die E-Mail bei Bedarf konvertiert. Der Konverter hat nicht besonders viel zu tun, da die Anwendung iso-8859-1 nutzt und die meisten E-Mails ebenfalls in iso-8859-1 oder ähnlichem daherkommen.

Kürzlich gab es Probleme mit utf-8-kodierten E-Mails, die jedoch nicht als solche erkannt wurden. Stattdessen behauptete imap_fetchstructure() steif und fest, die E-Mail wäre US-ASCII. Allerdings nur auf dem live Linux-Server. Auf unserem lokalen Server (Windows) wurden die E-Mails korrekt als utf-8-kodiert erkannt.

In den Kommentaren zu imap_fetchstructure() lässt sich ein Hinwis dazu finden:

If you are getting CHARSET as US-ASCII even if the header has a Content-Type: field, make sure the header also has a MIME-Version: field.

For example, the following header will correcty report charset as KOI8-R

MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"

Without the MIME-Version it will be reported as US-ASII

Und tatsächlich. Folgendes Script hat den Beweis erbracht.

$headers  = "MIME-Version: 1.0\n";
$headers .= "Content-Type: text/plain; charset=\"utf-8\"";

mail('info@example.com', 'Subject', 'Text', $headers);

Mit der Kopfzeile MIME-Version: 1.0 in der E-Mail hat der Server den Zeichensatz korrekt als utf-8 erkannt. Ohne die Zeile nicht.

Um Dateien zum Server hochzuladen, bietet sich Zend_File_Transfer_Adapter_Http an. Hier ein Code-Beispiel aus dem Manual.

$adapter = new Zend_File_Transfer_Adapter_Http();
$adapter->setDestination('/beispiel/pfad');
if (!$adapter->receive()) {
    $messages = $adapter->getMessages();
    echo implode("\n", $messages);
}

Erstes Problem: Aus einem unerfindlichen Grund nahm der Validator an, dass die Datei nicht hochgeladen wurde und eine "Attacke" vorliegen müsse.

Da das definitiv nicht der Fall war und ich erst einmal weiter machen wollte, habe ich den Validator kurzerhand abgeschaltet. Hinweis: Machen Sie das zu Hause bitte nicht nach. ;-)

$adapter->clearValidators();

Das hat zwar die Fehlermeldung verschwinden lassen, aber die Datei kam trotzdem nicht an, wo sie sollte. Vielleicht hilft ja die Aktualisierung auf Version 1.7 (von 1.6.2).

Mitnichten. Nun gab's eine Fehlermeldung dass ein Array-Index nicht existierte. Ein Bug, und laut ZF Bug-Tracker im SVN gefixt. OK, schnell mal (10 min, 60 MB) den aktuellen Trunk ausgecheckt. Und wer hätte es gedacht, nun funktioniert's.

Ist das nicht nett? O'Reilly bietet einige Bücher kostenlos als PDF-Datei für jedermann zum Herunterladen und Lesen an. Die Liste enthält neben Titeln zu PHP und Ruby auch einiges zu Linux und anderen Open-Source-Projekten.

Neu dabei ist das Werk „Praktischer Einstieg in MySQL mit PHP“ von Sascha Kersken. Das Buch hat 368 Seiten und die PDF-Datei wiegt rund 15 MB.

Wie der Titel schon sagt geht es um MySQL und PHP. Das Buch richtet sich an Anfänger und erklärt neben der Installation von Apache auch die Grundlagen von PHP und MySQL. Inklusive Installationsanleitung. Achja, phpMyAdmin wird auch erklärt.

Die Community ist in Aufruhr. Steffan Esser hat auf Grund der Diskussionen um den Namespace-Separator PHP geforkt.

:-D 

Hintergrund: Vor ein paar Tagen haben die PHP-Entwickler entschieden, statt Doppeldoppelpunkt, den Backslash als Trenner für Namensräume zu verwenden. Dagegen sträubt sich jedoch der eine oder andere. Erinnert angeblich zu stark an Windows-Pfade.

Ich persönlich hätte ebenfalls die Doppelpunkte favorisiert. Nüchtern betrachtet, macht's jedoch keinen Unterschied.

Phpinfo() ist nützlich. Phpinfo() erfüllt keinen anderen Zweck, als nützlich zu sein. Warum ein Server-Betreiber phpinfo() manipuliert und unter anderem die Anzeige der Umgebungsvariablen verhindert, wird wohl für immer ein Rätsel bleiben.

Im vorliegenden Fall war der Grund für den Griff nach phpinfo(), dass der Aufruf von getenv('REQUEST_URI') folgendes produzierte:

/www;example.com/beispiel/pfad/datei.php

Der Domain-Name im REQUEST_URI? Ein Semikolon im Domain-Namen? Da ist ja wohl alles falsch.

$_SERVER['REQUEST_URI'] im Gegenzug hat den korrekten Wert angezeigt.

/beispiel/pfad/datei.php

Zum Glück war es nur eine Stelle im Script, die geändert werden musste.

Antwort vom Kunden:

I got Lycos as provider. They somethimes got very strange methodes. The first time i also got problems with oscommerce.

Was lange wehrt... Nachdem PHP 5 seit Jahren verfügbar und auf vielen Servern parallel zu PHP 4 installiert war und ist, bietet den Aussagen Parallels zufolge Plesk ab Version 9 die Möglichkeit, mehrere PHP-Versionen nebeneinander zu betreiben.

PHP over Fast CGI

Site applications based on PHP implementation will now be executed faster and safer with PHP running in the Fast CGI mode. This enhancement allows running several PHP versions simultaneously.

Großartig. Für die Kombination PHP 4/ PHP 5 kommt das Ganze zu spät, aber PHP 6 wirft ja bereits seine Schatten voraus. Bleibt noch die Frage, wie einfach oder wie aufwändig es sein wird, die zwei PHP-Versionen auf den Server zu bringen. Wir werden sehen.

Verwandter Artikel: Plesk 9 ist verfügbar - halbwegs

Drei Möglichkeiten, um zu verhindern, dass Suchmaschinen Seiten mit angehängter PHP-Session-ID in ihren Index aufnehmen:

ini_set() im PHP-Script

ini_set('session.use_trans_sid', false);

.htaccess

php_flag  session.use_trans_sid off

robots.txt

User-agent: *
Disallow: /*PHPSESSID  

Nachtrag:

Die erste Methode per ini_set funktioniert nur bis PHP 4.2.3. Bei späteren PHP-Versionen funktioniet es nur per .htaccess oder, wenn PHP als CGI installiert ist, per php.ini. Letztere kommt in das entsprechende Verzeichnis auf dem Server und hat folgenden Inhalt:

session.use_trans_sid = 0

Wir berichteten vor kurzem, dass die Handhabung der PEAR-Klasse Net_FTP im Zusammenhang mit dem passiven Modus nicht ganz eindeutig ist. Kommentator JR hat deshalb auf pear.php.net eine Funktionsänderung vorgeschlagen und siehe da: Nur wenige Tage später wurde die FTP-Klasse entsprechend erweitert.

Ein Blick auf die verschiedenen Versionen der Klasse zeigt, dass der Entwickler den Aufruf zum aktivieren einer passiven Verbindung¹ erst im zweiten Anlauf an der richtigen Stelle platziert hat. Nämlich nach dem Login und nicht bereits schon nach dem Herstellen der Verbindung. Waren also nicht nur wir verwirrt. ;-)

Jetzt ist die Fußangel allerdings (fast)² beseitigt. Man kann nun setPassive() vor dem Herstellen der Verbindung, nach dem Herstellen der Verbindung oder nach dem Login aufrufen - der Effekt ist derselbe.

1) Eine passive Verbindung aktivieren? Das ist ja wie laufen gehen (joggen). 

2) Momentan allerdings funktioniert nur die bisherige Methode, denn folgender Code verhindert den automatischen Aufruf in der Methode login().

if (!$this->_passv) {
    $this->setPassive();
}

Das Ausrufezeichen ist zu viel. Beim Aufruf von setPassive() wird $this->_passv = true gesetzt. $this->_passv dann aber später auf false zu Prüfen haut nicht hin. Interessanterweise ist das Ausrufezeichen erst beim Umzug des Codes von der Methode connect() in die Methode login() dazugekommen. Merkwürdig, merkwürdig.

Nachtrag: 

Auf unseren Hinweis hin wurden auch die übrigen Fehler korrigiert. Funktioniert jetzt alles bestens. Vielen Dank dafür an dieser Stelle.

Auch wenn bei PHP-Funktionen wie timezone_identifiers_list() (bzw. DateTimeZone::listIdentifiers()) PHP 5 >= 5.1.0 als Verfügbarkeit angegeben ist, sollte man sich nicht zu früh freuen. Im Kleingedruckten steht nämlich:

Note: Experimental DateTime support in PHP 5.1.x

Although the DateTime class (and related functions) are enabled by default since PHP 5.2.0, it is possible to add experimental support into PHP 5.1.x by using the following flag before configure/compile: CFLAGS=-DEXPERIMENTAL_DATE_SUPPORT=1

Effektiv sind diese Funktionen also erst ab PHP 5.2.0 verfügbar. Dies nur so als Hinweis. Nicht dass hinterher wieder jemand sagt, er hätte es nicht gewusst. ;-)

Bei unserem News-Script verwenden wir die PEAR-Klasse XML_RPC, um Änderungen an die Ping-Dienste zu melden.

<?php

// Klasse laden
require_once 'XML/RPC.php';

// Liste mit Ping-Diensten
$list = array( 
    'ping.syndic8.com/xmlrpc.php',
    'blogsearch.google.com/ping/RPC2',
    'rpc.technorati.com/rpc/ping',
    'rpc.weblogs.com/RPC2'
    );

// URL des Weblogs
$baseURL = 'http://www.example.com/blog/';

// Name des Weblogs
$blogName = 'Mein Weblog';

// Die Liste der Ping-Dienste durchgehen und Daten senden
foreach ($list AS $key => $value)
{
    $value      = trim($value);
    
    // Ping-Dienst-URL in Host und Pfad trennen
    $pingHost   = substr($value, 0, strpos($value, '/'));
    $pingPath   = substr($value, strpos($value, '/'));
    
    // Blog-Name und URL als Prameter setzen
    $params     = array(
        new XML_RPC_Value($blogName, 'string'),
        new XML_RPC_Value($baseURL, 'string')
        );
    
    /**
     * weblogUpdates.ping als Modus auswählen. Alternativ könnte man auch
     * weblogUpdates.extendedPing verwenden und kann dann noch weitere Infos
     * übertragen.
     */
    $msg = new XML_RPC_Message('weblogUpdates.ping', $params);
        
    // Pfad und Host setzen
    $cli = new XML_RPC_Client($pingPath, $pingHost);

    // Daten übertragen
    $resp = $cli->send($msg);
        
    // Wenn ein Ping fehlgeschlagen ist, anzeigen welcher
    if (!$resp) {
        echo '<br />Ping fehlgeschlagen: ' . $value . ' -> ' . $cli->errstr;
        continue;
    }    

    if (!$resp->faultCode()) {
        /**
         * Wenn kein Fehlercode zurückgesendet wurde, hat vermutlich
         * alles geklappt
         */
        $val = $resp->value();
        echo '<br />Ping erfolgreich: ' . $value;
    } else {
        // Fehler anzeigen
        echo '<br />Ping fehlgeschlagen: ' . $value . ' -> ' . $resp->faultCode()
            . ' -> ' . $resp->faultString();
    }
}

?>

War diese Anleitung hilfreich? Über Hinweise oder Anmerkungen würden wir uns freuen.

In ein Kundenprojekt hatten wir eine Backup-Funktion eingebaut, die per FTP Datenbank und Dateien auf einen anderen Server überträgt. Das funktionierte auch bestens für mehrere Wochen. Dann meldete sich 1&1:

[...] unseren Server-Überwachungs-Tools ist eine Ihrer Anwendungen auf Ihrer Internet-Präsenz aufgefallen die einen "Dienst" auf jeder IP-Adresse die auf dem Server eingerichtet ist, installiert:

/.../cron/ftpbackup.php

Dies kann z.B. dadurch passieren, wenn Sie in Ihrem Script aktives statt passivem FTP verwenden.

Die Datei enthält ein Script, dass die PEAR-Klasse Net_FTP verwendet. Wir haben zu dieser Klasse bereits an dieser Stelle etwas geschrieben.

Und weiter:

Bitte haben Sie Verständnis und konfigurieren Sie deshalb Ihre Anwendung einfach um und zwar ausschliesslich auf die Ihnen von uns zugewiese IP-Adresse (zu finden z.B. im Konfigmenü Ihrer Präsenz unter dem Punkt "Technische Daten"), bzw verwenden Sie bitte ausschliesslich passives FTP in ihren Scripten.

Nichts einfacher als das. Haben wir also im PHP-Script passives FTP aktiviert. Dabei ist uns allerdings ein kleiner Fehler unterlaufen, welcher in der – aus unserer Sicht – irreführenden Bezeichnung der entsprechenden Methode der FTP-Klasse lag (siehe den Abschnitt "Fußangel"). Resultat war, dass passives FTP nicht aktiviert wurde. Das wusste zu diesem Zeitpunkt jedoch niemand. So schrieb dann der Support von 1&1 am nächsten Tag auch:

[...]unserem Überwachnungstool ist abermals Ihr cronjob /.../cron/ftpbackup.php aufgefallen.

[...]

Von dem Tool wird wohl wieder der Passive Mode für FTP bemängelt. Könnten Sie bitte nochmals danach schauen?

Nachdem wir also nun – aus unserer Sicht – extra auf passiv umgestellt haben, sollte das jetzt Auslöser des Problems sein? Merkwürdig. Aber kein Problem, haben wir also auf aktives FTP umgeschaltet.

Das hat das Problem wohl auch nicht gelöst. Deshalb kam erneut Post von 1&1:

[...]bitte das Script auf passives FTP umstellen. Die Umstellung auf passives FTP war schon richtig, weil durch passives FTP nur der FTP-Standard-Port benutzt wird und kein anderer Port. Nur hat in Ihrem Script der Passive Mode wohl nicht richtig gegriffen, sonst wäre dem Überwachungstool es nicht aufgefallen.

Und hier war dann der Support von 1&1 wieder auf der richtigen Spur. Nachdem wir tiefer in die Funktionsweise der Klasse und der PHP-Funktion ftp_pasv() eintauchten, wurde deutlich, dass passives FTP tatsächlich nicht aktiviert worden war. Ein kurzer Handgriff und auch das war erledigt.

Danke hiermit an den Support von 1&1 für die Hilfe und die Geduld. :-)