Schlagwortarchiv für: PHP

SektionEins: Security für Web 2.0 Applikationen

Björn Schotte teilte mir bereits gestern mit, dass eine Vereinigung von Chorizo sowie Stefan Essers PHP Patch „Suhosin“ in der neuen Firma „SektionEins“ ansteht. Stefan gehört zu den führenden Web-Security-Experten und Björn Schotte ist durch das PHP Magazin und seine Tätigkeit als einer der Geschäftsführer von MAYFLOWER bekannt.

Der Schwerpunkt der neuen Firma wird die Durchführung von Security Audits sein, die mittlerweile für jede neue Webanwendung auch vor dem öffentlichen Start oder dem Verlassen einer Beta-Phase eine Pflicht darstellen um die User und ihre Daten vor ungewollten Zugriffen schützen zu können. Security wird ja gerade bei Web2.0 Applikationen immer wichtiger, zumal sich SektionEins nicht nur auf PHP beschränkt sondern auch beliebige Webapplikationen prüft – egal ob Java, Ruby oder was auch immer an Software eingesetzt wird.

SektionEins startet dabei mit interessanten Bestandskunden aus dem Finanz- und Hosting-Bereich ebenso wie aus dem Web2.0-Startup-Bereich. Für die Ausgründung des erfolgreich laufenden Bereichs bei MAYFLOWER wird MAYFLOWER zusammen mit Stefan ein ziemlich großes Rebranding fahren, das Stück für Stück in den nächsten Tagen und Wochen insbesondere für Chorizo durchgeführt wird. Bereits schon jetzt kann man sich für den Launch der Webseite registrieren – man darf also wirklich gespannt sein auf das, was MAYFLOWER und Stefan auf die Beine stellen werden.

Nachtrag: Kurz etwas korrigiert und aufs blog.thinkphp.de verlinkt ;)

/von

Videointerview mit sevenload

,

Björn Schotte vom PHPMagazin hat das Videointerview für sich und seine Kunden entdeckt. Unter dem ThinkPHP Blog findet sich das erste Video seiner Interviewserie mit unserem Chief Software Architect Thomas Bachem von sevenload.de.

Warum er sich auf die Videotechnologie für Interviews einlässt, verrät Björn natürlich auch in seinem Artikel:

Warum Videos? Nun, zum einen gibt es das noch nicht im PHP Bereich, und ich bin froh, mal wieder der Erste (nach dem weltweit ersten PHP Kongress und dem weltweit ersten Print-Magazin zu PHP :-) ) sein zu können, und hoffe, dass es viele Nachahmer findet.

Das Blog von Björn habe ich dementsprechend natürlich abonniert, um auch in Zukunft wichtige technikrelevante Informationen und die schönen Videointerviews verfolgen zu können.

/von

WP-Cache 2

Seit heute Abend lassen wir das Plugin WP-Cache 2 laufen. In der vorigen Woche bekamen wir intensive Probleme mit dem Plugin, da während des Cachings selbst der Output irgendwie hängen blieb. Zuerst dachte ich an ein Problem mit unserem mod_rewrite. Doch mit zahlreichen echo „error1“; Bastelaktionen kam ich dem Geheimnis hinter. Nun habe ich mich durch all die Funktionen geforscht und stellte fest, dass eine kleine Inkompabilität im Programm mit höchstwahrscheinlich der auf unserem Server eingesetzten PHP Version 5.1.2 und Apache/2.0.52 Version zusammenhängt.

Genau kann ich das natürlich nicht behaupten, jedoch half es in Zeile 219 der Datei wp-cache-phase2.php folgendes zu ändern:

Zeile 219: ob_end_clean();
ändern in
Zeile 219: // ob_end_clean();

Einfügen in Zeile 232: ob_end_flush(); // unsere Modifikation

Das ursprüngliche flush() Kommando, was ich vorsorglich in dem Script belassen habe, verhält sich sogar laut php.net ein bisschen irreführend:

Server modules for Apache like mod_gzip may do buffering of their own that will cause flush() to not result in data being sent immediately to the client.

Sei’s drum, nun haben wir das ganze mit dem ob_end_flush() gelöst. Schön anzusehen ist dabei, dass die meisten Caches nur ausgespuckt werden, wenn das Original mit den Datenbankabfragen nicht innerhalb von 1 Sekunde geladen wird… hmmm!

Problem: Siehe die Kommentare. Es wird so anscheinend nichts mehr im Cache gespeichert. Sofern noch etwas altes im Cache drin ist, wird das zwar ausgegeben, doch keine neuen Dateien werden im Cache erzeugt.

Nachtrag: Mir fiel ebenfalls auf, dass das durch WordPress initierte GZIP-Encoding (Admin -> Options -> Reading -> WordPress should compress articles (gzip) if browsers ask for them) den gesamten Seitenaufbau verlangsamt hat, bevor ich WP-Cache 2 aktiviert habe. Gewiss, eine kleine Funktion zum Zippen muss vom Webserver bei jedem Seitenaufruf gestartet werden, aber anscheinend nahm es Ausmaße von über 1 Sekunde pro Seite an. Jetzt ist die Ladezeit recht gering… ok, ich sollte Feierabend machen! ;)

/von