Das PHP BBQ 2010 in Frankfurt am Main steht: Sonntag den 27. Juni ab 13:00 Uhr im Licht- und Luftbad am Niederräder Ufer. Die Teilnehmerzahl ist begrenzt, mehr Infos in der Mailingliste.

Außerdem bietet die FrOSCon Projekten rund um Freie Software die Gelegenheit, sich mit einem eigenen Stand zu präsentieren, oder einen eigenen Raum zu gestalten. Denkbar sind hier Entwicklertreffen genauso wie eigene Vortragsreihen oder Workshops.

PHP @ FrOSCon 2010

Auch in diesem Jahr veranstaltet die PHP Usergroup Dortmund einen vollständigen Track unter dem Motto PHP @ FrOSCon. Für diesen Track läuft ein eigener Call For Papers bis zum 23.05.2010.

Daneben wird es einen “PHP-Room” geben, das die ganze Zeit geöffnet ist für Hacks, Diskussionen und eine Pläuschchen. Andere Usergruppen aus Hamburg, Köln/Bonn und Bielefeld werden ebenfalls anwesend sein.

Alle Infos zur PHP @ FrOSCon 2010 gibt es auf der Website: http://froscon.phpugdo.de/.html.

FrOSCon Call of Papers und Projects

Ebenfalls für “nicht PHP-Vorträge” wurde eine Website eingerichtet: http://cfp.froscon.de . Interessierte Projekte können sich ab sofort unter https://callforprojects.froscon.org/ für einen Stand oder einen Raum bewerben.

Ich kann die Konferenz nur empfehlen, auch für Projekte und Gruppen bietet dies eine sehr gute Gelegenheit mit Usern und potentiellen Entwicklern zusammen zu treffen.

Eine europäische/internationale PHP Unconference ist für ein Wochende im 4. Quartal 2010 geplant. Ort der Austragung sollte (ursprünglich, s.u.) auf Mallorca sein. Dort kann es ja auch ganz schön im Winter sein. Chillout in der heissen Abendluft ist dann aber eher nicht angesagt, also wird die Warmup-Party am Freitag Abend warscheinlich nicht auf einem Boots-Deck stattfinden.

Judith Andresen und Markus Wolff, beide erfahrene Leute von der PHPUnconference in Hamburg, organisieren das Event. In einem Interview von Nils Langner vom Blog PHP Hate Me für das PHP Magazin sprechen sie über ihre Pläne die sich im Anschluss der Konferenz in 2009 geformt haben.

Es werden voraussichtlich 200 TeilnehmerInnen erwartet, ein Ort wird noch gesucht. Mehr Informationen gibt es auf dem Blog und in Judith Andresen’s phpeuc Twitter Feed. Der Zeitpunkt wurde gewählt, um nicht zur Haupsaison auf die Insel “zu müssen” (Übernachtung sollte nicht zu teuer sein), der Ort weil es von überall aus Europa recht günstig ist, dort hinzugelangen. Auch soll der Sonntag so eingerichtet sein, Rückflüge am gleichen Tag nehmen zu können, falls man es sich nicht anders legen konnte.

Die bei der Adhoc-Konferenz in Hamburg letztes Jahr dabei waren wissen allerdings, dass internationale Besucher bisher zwar gewünscht aber rar gesät waren. In diesem Licht kann die Konferenz also auch als Versuch gewertet werden, das endlich mal zu ändern . Gut so!

Die Organisatorin bittet nun um Unterstützung bei der Suche nach einem geeigneten Ort für die erste europäischen PHP Unconferenz.

Seit 31. März ist der Ticketverkauf für die diesjährige PHP Unconference Hamburg ausgerufen worden. Ich kann die Veranstaltung nur wärmstens empfehlen. Mehr Infos gibts auf dem Blog zur Unconference. Achso: die Tickets sind immer ziemlich schnell weg.

Zur Feier das Tages startet um 10 Uhr ein Gewinnspiel. Also jetzt.

In diesem Code wird auf die Onlinebanking Software Hibiscus mittels der dortigen XML-RPC Schnittstelle zugegriffen. Dafür wird die Bibliothek XML-RPC for PHP verwendet. Natürlich ist der Quellcode mitlerweile veraltet. Auch ist er nicht mit der aktuellen Hibiscus Version getestet. Und die Bibliothek ist sicherlich auch weiter gepflegt worden. Und so kann es passieren, dass beim Beispielcode Fehler beim Anlegen von Überweisungen auftreten. Doch wie damit umgehen?

Dies hat wohl dazu geführt das viele Leute die hier den Beitrag gelesen haben und sich den Quellcode gezogen haben sich nicht an mich direkt als Autor sondern an den Autor von Hibiscus gewandt. Auch in den Kommentaren ist nicht viel zu finden. So habe ich erst seit einigen Tagen die Gelegenheit mich mit dem Problem zu beschäftigen.

Leider muss ich anfügen. Nun kann wohl Hibiscus selber am wenigsten was dafür, wenn die in PHP eingesetzte XML-RPC Bibliothek einen Fehler hat. Sie kann wohl offensichtlich nicht mit Namespaces umgehen, die RPC-Response enthält aber solche. Das zeigt die Antwort auch an, es handelt sich um die XML-RPC implementierung von Apache. Es kann also zu einem Fehler kommen. Und dafür ist der Autor von Hibiscus nicht der naheliegenste Ansprechpartner. Wenn man Beispielcode nimmt, dann sollte man diesen als praktische Gelegenheit begreifen, ihn zu lesen und zu verstehen. Dazu gehört auch der Umgang mit Fehlern darin. Eigentlich sogar ein willkommener Anlass solch ein Fehler, stellt er doch quasi eine Prüfung dar, ob man verstanden hat wie es funktioniert, wenn man den Fehler löst. Ein einfaches Copy and Paste gibt einem diese Sicherheit nicht, sondern lässt einen in dem trügerischen Gefühl, ein schnelles Ergebnis erzielt zu haben. Dabei entzieht sich dieses Ergebnis der vollen eigenen Kontrolle.

Aber was tun? Da es sich bei allen Komponenten um quelloffene, Freie Software handelt drängen sich zwei Lösungen auf: Eine konkrete, der Fix oder Workaround, und eine strategischere, das Feature. Der Produzent sollte natürlich auch eingebunden sein, allerdings rate ich sehr dazu, Entwickler in freien Projekten nicht mit unausgegorenen Emails zu belästigen. Das stellt man am besten dadurch sicher, erstmal selber zu schauen, was der Auslöser des Fehlers ist. Vielleicht liegt der ja auch bei einem selber. Und was auch nervig ist: Wenn ein Benutzer einfach mal eine Mail an alle Adressen schickt die er hier oder da findet und meint: das könnte schon passen, was kümmerts mich, wenn ich andere für mich denken lassen kann.

Eine Entwicklerin, die auf einen Fehler stösst, fängt automatisch an, ihn zu analysieren.

Eine Entwicklerin, die auf einen Fehler stösst, fängt automatisch an, ihn zu analysieren. Ist die Fehlerursache bekannt, so kann sie gefixt werden. Dazu muss man meist sogar nur wenig Ahnung haben, was ein Programm da gerade macht. Ein komplettes Verständnis aller Komponenten und Hintergründe ist sicherlich hilfreich aber nicht zwingend. Heraus kommt dann ein Workaround evtl. wie dieser hier:

Das wäre also ein Fix oder Workaround. Wie alles sind natürlich auch Fehler relativ. Konkret ist mit einem Workaround also geholfen. Und zwar schnell und einfach. Steht es hingegen an, sich um den Kern des Problems zu kümmern, so ist ein wenig mehr Arbeit und Genauigkeit von Nöten. Hier ist der Fix aber nicht umsonst, hat er doch geholfen, den Fehler einzugrenzen und die Funktionsfähigkeit wieder herzustellen.

So stellt sich erstmal die Frage warum genau der Fehler zu Tage tritt und warum der Fix nun funktioniert. Die Eingrenzung des Fehlers auf seine ausschlaggebende Ursache. Bei diesem Beispiel ist es relativ einfach mit der Fehlerursache. Auch das Protokoll von XML-RPC ist relativ offen, den es basiert auf (recht einfachen) XML Dokumenten, die per HTTP ausgetauscht werden. So ist zum debuggen mittels PHP das XML der Antwort einsehbar indem der String ausgegeben wird:

Der Fehler tritt hier auf, weil die PHP XML-RPC Bibliothek nichts mit dem Rückgabewert “<ex:nil/>” anfangen kann. Nun stellt sich die Frage, wie damit umgehen? Wo genau liegt der Fehler, in der PHP-Bibliothek oder in der Implementierung in der Java-Bibliothek von Apache? Wenns um Bibliotheken geht ist das oft ein Zeichen dafür, dass es sich hier um eine grundlegendere Frage handelt. Und das eine Lösung aufwendiger und auch problematischer sein kann. Dies aus zwei Gründen:

Zum einen werden Bibliotheken von vielen Programiererinnen und Anwendern in unterschiedlichen Anwendungen genutzt dessen allen Bedürfnisse eine Bibliothek unter einen Hut bekommen muss. Eine “Fehlerbehebung” die zu nicht erwartenen Ergebnissen führt kann zum Beispiel bestehende Anwendungen gefährden.

Zum anderen, weil wenn ein Fehler gefunden wird, ein Fehlerbericht an das Projekt der Bibliothek gemacht werden sollte. Dazu muss erstmal rausgefunden werden, wie dies gemacht wird und es ist oft nicht klar, wie schnell ein Fehler im Projekt behoben wird, nachdem er gemeldet wird.

Mein Code, Dein Code, unser Code.

In der Programmierung spricht man hier oft vom “Upstream”. Ich erstelle für die lokale Kopie meiner Bibliothek einen Patch, der das gewünschte Feature implementiert. Das Feature für die PHP-Bibliothek ausführlich formuliert wäre hier: Die Unterstützung des ex:nil Rückgabewertes zwecks Kompabilität zur Apache XML-RPC Implementierung.

Läuft der Patch bei mir und bin ich sicher, dass das auch für andere AnwenderInnen der Bibliothek Sinn macht, upstreame ich den Patch, in dem ich den dem Bibliotheksprojekt zur Verfügung stelle. Meist wird darüber diskutiert was für und was gegen den Patch spricht und der Patch entsprechend modifziert resp. erweitert. Wird der Patch akzeptiert, landet er meist im nächsten Release des Projektes.

Keep Up the Upstream.

Damit ist dann allen geholfen. Übrigens sind viele Entwicklerinnen dann für Feedback dankbar, wenn es um eine reale Fehlerlösung geht. So hat der Entwickler im Hibiscus Projekt sicherlich kein Interesse daran, PHP-Programmierern bei der Fehlersuche zu helfen, selbst wenn er ein ganz lieber ist und es mit den Anfragen auch generell recht freundlich hält. Hätte die Schnittstelle auf seiner Seite einen Fehler würden sich warscheinlich schon recht viele Leute beschwert haben… . Das XML-RPC for PHP Projekt hingegen hat aber vielleicht ein echtes Interesse daran, die Bibliothek kompatibel mit der Apache Implementierung zu halten. Jeder Fehler ist eine Chance ein Programm zu verbessern. Keep Up the Upstream.

Eine “PHP BBQ Tour” ist eine einwöchige Rundreise durch die PHP-UGs in Deutschland. UG-Teilnehmer sind herzlich eingeladen von Station zu Station mitzureisen und sich auszutauschen.

Jede UG organisiert das (Abend-)Programm vor Ort. Sie findet einen Platz, um ein BBQ auszurichten. Ob überhaupt und welche Vorträge, Workshops, Diskussionen etc. am Abend stattfinden ist Sache der UG. Beispielsweise kann eine UG eine Art “Mini-Unconference” oder einen “Wunschfilmabend” mit Open-Air Kino ausrufen.

Als Route schlage ich eine Fahrt von Süd (München) nach Nord (Kiel) vor Zum einem bleibt es dann von Tag zu Tag länger hell und das Licht geht nicht aus sondern an am Ende der Tour, zum anderen beginnt am 20.06.2009 die Kieler Woche – http://www.kieler-woche.de . Die Kieler Woche ist immer eine Reise wert.

Auf der Wiki-Seite habe ich eine mögliche Reiseroute skizziert:

http://forge.mysql.com/wiki/PHP_BBQ_Tour

Route:

Montag, 15.06 – München
Dienstag, 16.06 – Frankfurt?
Mittwoch, 17.06. – Karlsruhe
Donnerstag, 18.06. – Berlin
Freitag, 19.06. – Dortmund?
Samstag, 20.06. – Hamburg
Sonntag, 21.06. – Kiel

Seit der tollen PHP Unconference 2008 wünsche ich mir eine solche “PHP BBQ Tour”. Ich würde gerne einmal die UGs kennenlernen. Weil ich reisen möchte, biete ich an, die übergeordnete Organisation zu übernehmen.

Nach einem Jahr bietet sich mir eine gute Gelegenheit die Idee zu realisieren. Mein Chef (Georg Richter) hat mir ermöglicht für mich anfallende Reisekosten für eine Dienstreise zur MySQL User Conference in die USA gegen meine Reisekosten für eine PHP BBQ Tour einzutauschen. Dieser Tausch wurde möglich, weil ich im Gegenzug anbot die BBQ-Tour in meinem (MySQL Rest-)Urlaub bis zum 30.06.09 anzutreten.

Natürlich biete ich jeder interessierten UG an Vorträge zu Sun/MySQL-Themen zu organisieren und vielleicht kann ich auch Speaker gewinnen, die normalerweise nicht an einer PHP-UG Sitzung teilnehmen. Ich knüpfe mein Engagement jedoch an keinerlei Bedingungen solange nicht direkte Mitbewerber von Sun/MySQL involviert werden.

Ich freue mich auf Eure Rückmeldung und Eure Fragen!

Grüße,
Ulf

Wer ist “Ulf Wendel”? Ich arbeite seit etwa fünf Jahren für MySQL.
Seit geraumer Zeit bin ich an der Entwicklung der MySQL Treiber für
PHP, C++ und OpenOffice.org beteiligt. Davor war ich bei MySQL als
Supporter, Trainer und Consultant für MaxDB zuständig. Bevor ich zu MySQL gegangen bin, habe ich meine Brötchen mit der PHP-
Anwendungsentwicklung – zuletzt bei Mayflower/Hypovereinsbank -
verdient. Seit 2003 findet man mich selten auf PHP-Kongressen als
Redner und in PHP-Zeitschriften als Autor. Aber ich erinnere mich gut an manch einen Grillabend: das hat einfach Spaß gemacht.

Warum nicht noch einmal…

–
Ulf Wendel, MySQL

ESAPI definiert Sicherheitsmaßnahmen, die eine Webanwendungen gegen typische Angriffe wie Cross-Site-Scripting und SQL-Injection schützen.

Ein erster Termin ist mit Mai 2009 angegeben. Dabei handelt es sich um eine Portierung der JAVA Referenzimplementierung. Mehr Infos auch im Blog von Andrew van der Stock.

In der LGPL-Klasse drin werkelt ein recht leichtgewichtiger Code, der vor allem von regulären Ausdrücken Gebrauch macht statt bis ins letzte Detail standardkonform HTML zu parsen. Dann bleibts auch speedy, zumindest bei der Aufwand/Nutzen Rechnung. Komprimiert werden HTML, CSS und Javascript on-the-fly. Dabei lässt sich das auch konfigurieren, zb. wenn nur CSS oder HTML komprimiert werden soll. Ein Plugin für Wordpress wird ebenfalls bereit gehalten. Getestet hat der Autor seine Klasse mit Firebug und gegen YSlow.

Natürlich wissen bestimmt viele Leserinnen und Leser die Vorzüge Quelloffener und Freier Software zu schätzen. So geht es auch mir. Aber manchmal kann man nur in Abgrenzung die Vorteile deutlich machen. Also was tun, wenn dann mal schnell und preiswert ein PHP Encoder her soll? Ich hatte die Möglichkeit den PHTML Encoder Pro von RS Software Lab als auch den Ioncube PHP Encoder von Ioncube Ltd. miteinander im Einsatz zu messen. Beide sind relativ preiswert (120 und 200 Dollar) und können per Kreditkarte als Download bestellt werden.

PHTML Encoder Pro

• Unterstützt ein OS: Linux oder Windows (kleinste Version).
• Preis: ca. 120 US-$
• Das Prinzip der Software ist, das eigenen Loader-Dateien erstellt werden. Deswegen muss man die PHP Versionen quasi “selbst” unterstützen, hier gibt es keine vorgefertigten Loader. Dies kann bestimmt sicherer sein als vorgefertigte Loader, es ist aber auch ein grösserer Aufwand.
• Usability: Sehr schlecht. Erst war nicht klar, welche Version gekauft werden sollte, die Oberfläche ist nicht wirklich Bedienbar und die Anwendbarkeit des fertig encodierten Produktes ist recht limitiert wenn man sich das ganze vorher als “einfach” vorstellt bzw. lediglich die Free-Version probierte die sich in wesentlichen Prinzipien nicht mit der PRO Version deckte.
• Bestelldauer / Lizensierung: Schnell, ca. 1 Tag.
• Support: Per Email, Antwort innerhalb von einem Tag. Fachlich Kompetent.
• Dokumentation: Sehr schlecht, kaum vorhanden, das Prinzip und die Vorgehensweise kann vorher nur schlecht überblickt werden und macht das Produkt damit lediglich per Selbst-Test auswählbar.
• Service: Eine falsch bestellte Version wurde ohne Probleme gegen die richtige getauscht. Sehr entgegenkommend.

Ioncube PHP Encoder

• Unterstützt Linux und Windows (kleinste Version).
• Unterstützt viele PHP Versionen “out of the Box”.
• Preis: ca. 200 US-$
• Usablity: Die Software kann in einer kostenlosen Version evaluiert werden. Damit angelegte Projekte können direkt mit der Lizensierten Version verarbeitet werden. Die Windows GUI ist sehr einfach zu bedienen.
• Bestelldauer / Lizensierung: Recht Aufwendig. Die Bestellung der Software bis zum ersten Einsatz dauert ca. 2 bis 3 Tage, mehrfacher Kontakt mit dem Anbieter ist dafür notwendig. Die Lizenbedingungen sind eher abschreckend, die Software versucht sich mit einem Lizenzschlüssel der an die MAC Adresse eines Netzwerkadapters zu binden. Sollte das System verloren gehen, so geht auch die Lizenz verloren sofern man keinen Support mehr hat. Support ist auf die ersten 12 Monate limitiert. Hier empfliehlt sich die Installation in einer virtuellen Umgebung, evtl. unter Wine. Dies erfordert dann wieder einen höheren Aufwand in der Installation, ist zur Absicherung gegen einen zu starken Vendor Lock-In evtl. überlegenswert. Ansonsten sollte man davon ausgehen, das die Software für 12 Monate voll benutzbar ist.
• Support: Forum auf der Website, Support in den ersten 12 Monaten per Email möglich, ich habe den Email-Support nicht in Anspruch genommen und kann nicht sagen wie gut er ist.
• Dokumentation: Brauchbar. Sowohl mit der Software, bei den Loadern als auch Online auf der Website des Herstellers.
• Service: Alle Prozesse um die Bestellung liefen automatisiert und man hatte nie persönlichen Kontakt. Die Bestellung muss bei diesem Anbieter erst bestätitgt werden, dies geschieht in England zu normalen Geschäftszeiten Werktags. Bestellung über das Wochenende oder Feiertage verlängern den Vorgang entsprechend.

Fazit

Ein bischen habe ich mich gefühlt Äpfel mit Birnen zu vergleichen. Der Iconcube PHP Encoder ist ganz klar das bessere Produkt für einen schnellen Einsatz. Beim PHTML Encoder Pro handelt es sich vom Eindruck her eher um das Produkt eines einzelnen Entwicklers, das weniger nach Gesichtspunkten der Anwendbarkeit und Dokumentation entwickelt wurde. Iconcube bekommt in vielen Performance-Vergleichen sehr gute Noten und schneidet teilweise auch besser als der wesentlich teurere Encoder von Zend ab. Hinzu kommen eine sehr nette GUI und eine brauchbare Testversion. Die kostenlose Version vom PHTML Encoder ist nämlich nicht mit der Funktionsweise des PHTML Encoder PRO voll zu vergleichen. Hier tat ein Projekt welches in der kostenlosen Variante funktionierte, seinen Dienst in der “Pro” Variante nicht und hier bedarf es einer grösseren Anpassung in der Erstellung der Loader.

Sicherheitsaspekte konnte ich im Praxistest kaum abwägen. Iconcube PHP Encoder setzte laut eigener Dokumentation auf eine Kompilierung in PHP Bytecode der dann nochmal verschlüsselt wird. Ob die Kompilierung in Bytecode beim PHTML Encoder Pro gemacht wird, kann ich gar nicht sagen. Ab und an gibt es zum Thema auch interessante Diskussionen in Newsgroups, auch zum Encoding und des Schutzes allgemein. Ob ein starkes und solides kryptographisches Konzept bei den Lösungen verwendet wurde, kann ich in beiden Fällen nicht sagen. Beim PHTML Encoder Pro zumindest werden Angaben zu standarisierten Verschlüsselungsverfahren gemacht, was zumindest ein Signal ist, das hier nicht auf proprietäre Algorithmen gesetzt wird, die oftmals sich dann als eine Schwachstelle herausstellen. Auch könnte beim PHTML Encoder Pro aus Gesichtspunkten der Sicherheit der “echte” private Schlüssel überzeugen. Sollte deswegen der Einsatz überlegt werden, so ist eine längere Phase zur Einführung mittels Tests und Build-Automation überlegenswert, um die Schwachpunkte der Usability der Software auszubügeln. Hier kommt einem sicherlich der schnelle Support per Email zugute. Man muss sich allerdings auf die Software einlassen was für eine schnellen Einsatz weniger in Frage kommt, bei der Integration in eine Strategie allerdings überlegenswert sein kann zumal es hier auch die Option gibt, die Software im Quellcode zu erwerben.

Sollte man den nicht kurzfristigen Einsatz vom Iconcube PHP Encoder planen, so sollte man die Kosten genau kalkulieren und seine Investition evtl. mittels Virtualisierung absichern, was auch zu einem größeren Aufwandwand führt.

Alternativen

Da gibts die Variante von Zend. Ich habe den nicht eingesetzt, ich denke hier kann man aber bedenkenlos erstmal zu einer kostengünstigeren Variante eines anderen Herstellers greifen um die ersten Gehversuche zu machen. Sollte man danach das Bedürfniss haben, ein teureres Produkt zu lizensieren, so kann auch zum Zend Produkt gegriffen werden, welches einen vergleichbaren Funktionsumfang wie der Iconcube Encoder verzögert bereitstellt (ca. 1/2 bis 1 Jahr später).

Nicht-Kryptographisch aber zumindest Byte-Kodiert bietet sich noch der bcompiler aus dem PECL Repository an. Dieser erfordert eine stärkere Einarbeitung und Tests auf Zielsystemen. Dank seines Open Source Charakters ist hier allerdings auch viel mehr möglich und lädt zum experimentellen Einsatz ein.

Links

• PHTML Encoder Pro
• Ioncube PHP Encoder
• Zend Encoder / Zend Guard
• BCompiler PECL Package
• Slides for “Vulnerability Discovery in Closed Source/Encrypted PHP Applications” von Stefan Esser