Archive for April, 2011
Extending and Embedding PHP
Im Februar habe ich von Andre das Buch Extending and Embedding PHP von Sara Golemon angeboten bekommen, und da ich noch keinen tieferen Blick in die Erstellung von PHP Extensions geworfen habe, habe ich zugeschlagen. Wie man bei Amazon lesen kann ist es DAS Standard-Buch wenn es um PHP Erweiterungen geht. Allgemein gibt es über die Innereien von PHP nur wenig Literatur, umso interessantere Einblicke gibt das Buch.
Die 410 Seiten beginnen mit einem Überblick über den PHP Lebenszyklus. Wie verhält sich PHP im CLI Modus, in einer Multi-Prozess-Umgebung, in einer threaded-Umgebung oder wenn PHP in eine andere Applikation eingebettet wird? Es gibt definierte Initialisierungspunkte, in die sich eine Extension einhängen kann (bzw. muss), und eine threaded Umgebung ist nicht ganz problemfrei wenn es um Datenzugriff etc. geht. Auf jeden Fall interessante Einblicke, was PHP so beim „Start“ tut.
PHPStorm 60% günstiger! Bis zum 30.04.2011
Als Ostergeschenk gibt JetBrains 50% Rabatt auf PHPStorm ab heute bis zum 30.04.2011. Zusammen mit meinem Gutschein über 20% ergibt das insgesamt 60% Rabatt! Statt 99€ nur noch 39€!
Die neuesten Features, die in 2.1 kommen werden, sind übrigens:
- Eingebaute jQuery Dokumentation
- .htaccess Unterstützung (Autovervollständigung und Erkennung von URLs)
- NodeJS support plugin
- Eine Datei aus der Autovervollständigung entfernen (sinnvoll falls man mehrere Versionen von mootools/jQuery in seinem Projekt liegen hat)
Außerdem ist ein Jira-Connector in Planung. PHPStorm rockt!
Ein eigener Zend_Auth_Adapter gegen einen IMAP Server
Mit Hilfe von Zend_Auth kann man wunderbar Authentifizierungen durchführen, und dem Zend Framework liegen auch bereits einige Adapter bei, wie zum Beispiel DbTable, Digest, Http, InfoCard, Ldap und OpenId. In einem meiner Projekte wollte ich gegen einen IMAP-Server authentifizieren, jeder der einen IMAP-Account hat soll sich auf der Webseite einloggen können. Dazu habe ich einen kleinen Auth-Adapter geschrieben, den man so benutzt:
// authenticate against imap
$imapAdapter = new App_Auth_Adapter_Imap($this->_applicationIni->imap->host);
$imapAdapter->setIdentity($formData['LoginName'])
->setCredential($formData['LoginPassword']);
$result = $imapAdapter->authenticate();
if (!$result->isValid()) {
// Authentication failed
} else {
// Authentication successful
}
Der genutzte Adapter sieht so aus:
PHP 5.3 Feature: Late static binding (LSB)
PHP 5.3 brachte unter anderem auch Late-Static-Binding (LSB). Ich würde tippen, dass einige von euch wissen was das ist, aber nur sehr wenige von euch dieses Feature bisher benötigt und eingesetzt haben. Ich möchte hier zwei kleine Beispiele zeigen, an dem klarer wird, wofür LSB benötigt wird:
class ClassA {
public static function getName() {
return self::name();
}
public static function getNameLSB() {
return static::name();
}
public static function name() {
return 'ClassA';
}
}
class ClassB extends ClassA {
public static function name() {
return 'ClassB';
}
}
echo ClassB::getName(); // ClassA
echo ClassB::getNameLSB(); // ClassB
Je nachdem ob self:: oder static:: genutzt wird, wird einmal die Elternmethode und einmal die Kindmethode aufgerufen. self:: bindet sich früh (beim Kompilieren) an seine Klasse, static:: erst bei der Ausführung (dann an die Kindklasse).
Passwortrichtlinien, was tun und was nicht?
Vor kurzem bin ich wieder auf das leidige Problem „Passwortrichtlinien“ gekommen.
Erster Punkt: Xing
Das Minimum für das Passwort bei Xing beträgt 4 Zeichen. Von einer Pflicht, doch mindestens eine Zahl oder ein Sonderzeichen oder Großbuchstaben zu verwenden weit entfernt. Ist das nicht eine Einladung für Hacker/Cracker?
Zweiter Punkt: NGZ
Bei NGZ habe ich einen Account, um den Rootserver eines Bekannten zu administrieren. Immerhin können dort zusätzliche Accounts eingerichtet werden, und der Besitzer muss nicht seinen Login weitergeben. Allerdings wurde mir bei Benutzung der „Passwort vergessen“ Funktion mein Original Passwort per Email zugesandt! Sprich, Passwörter stehen dort im Klartext in der Datenbank, und sie werden in unverschlüsselten E-Mails durch das Internet geschickt und wohlmöglich von einigen per unverschlüsseltem WLAN abgeholt. Dann nützt auch https nichts für die Webseite.
Dritter Punkt: Sparkasse
Ich weiß ja nicht wie es bei euch ist, aber bei meiner Sparkasse muss man ein exakt 5-stelliges Passwort angeben. Das schränkt die Möglichkeiten sehr stark ein und ein wirklich sicheres Passwort ist damit nicht möglich. Selbst die Sonderzeichen sind auf öäüÖÄÜß beschränkt, warum nicht die anderen Sonderzeichen wie ()$%#+ usw? Warum zum Teufel tut das eine Bank?
Wie lauten eure Passwortrichtlinien, privat oder beruflich? Welche Schranken haltet ihr für zu niedrig und welche sind evtl. auch zu hoch? Wie speichert ihr Passwörter in der Datenbank, im Klartext, MD5/SHA1 gehasht, mit Salt oder ohne, oder sogar mehrfach gehasht? Welche „Passwort-vergessen“ Funktionalität haltet ihr für sinnig und welche für sinnlos bzw. sogar gefährlich?
