Als Beispiel möchten wir die Systemlast eines Servers im SecondLife Chat-Fenster ausgegeben. Hierfür benötigt man auf Serverseite ein kleines PHP Script, das die Systemlast vorformatiert zurückliefert. Dieser Code sieht bspw so aus:

1
2
3
4
5
6

function myNF($key) {
	return number_format($key,2);
}
 
$load = sys_getloadavg();
echo join('|',array_map("myNF",$load));

Es wird die sys_getloadavg-Funktion benutzt, um an die Systemlast zu gelangen. Diese wird noch ordentlich formatiert und in einem String zusammengefasst, wobei das “Pipe”-Symbol als Separator dient. Auf der anderen Seite möchten wir die einzelnen Strings ja auch wieder trennen und dabei noch etwas lernen; namlich wie man ein explode in LSL realisiert.

Im SecondLife benötigt man neben einem Benutzerkonto auch einen Platz, auf dem man Objekte generieren kann. Die Rechteverwaltung lässt dies nämlich nicht überall zu. Am einfachsten nutzt man für solche Tests die dafür vorgesehenen Sandboxen, die man über die Suche von SL sehr leicht finden kann.

Man generiert sich hier nun ein 3D-Objekt, mit dem man anschließen das eigentliche Skript verknüpft. Das Skript, das die Anfrage an den Server stellt, ist in LSL geschrieben. LSL steht für Linden Scripting Language und ist die Skriptsprache, die innerhalb von SL dem Benutzer zugänglich gemacht wird.

Im Content des 3D-Objekts legt man nun ein neues Skript an und ersetzt den Beispielquelltext durch den folgenden Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

key    httpd_id;
 
default
{
    on_rez(integer param)
    {
        llResetScript();
    }
 
    touch_start(integer num)
    {
        if(llDetectedKey(0)==llGetOwner())
        {
            // URL anpassen !
            httpd_id = llHTTPRequest("http://www.example.de/test.php",[HTTP_METHOD,"GET"],"");
        }
    }
 
    http_response(key id, integer status, list metadata, string body)
    {
        if ( id == httpd_id )
        {
            list myList = llParseString2List(body,["|"],[]);
            integer i = llGetListLength(myList);
            integer j = 0;
            for(; i>0 && j<i;j++) {
                llSay(0,llList2String(myList,j));
            }
        }
    }
}

Sobald dieser Code gespeichert wurde, wird durch Berühren des Objekt die Systemlast im Chat in 3 Zeilen ausgegeben. Zu beachten ist hierbei, dass nur der Besitzer des Objekts diese Aktion anstoßen kann. Somit ist in gewissem Maß ein Mißbrauch ausgeschlossen.

Im default-Block kann man 3 Eventhandler sehen on_rez, touch_start und http_response.

on_rez:
In diesem Handler wird das aktuelle Skript zurückgesetzt. Der Status des Skripts wird auf default gesetzt und die EventQueue geleert. Variablen werden auch neu initialisiert. Das on_rez Event wird beim Ablegen eines Objekts auf dem Boden gefeuert. Somit wird hier sichergestellt, dass man von einem wohldefinierten Zustand des Objekts ausgehen kann, wenn man es neu benutzen möchte.

touch_start:
Dieses Event wird gefeuert, wenn ein Avatar ein Objekt berührt. Genauer, wenn er damit beginnt es zu berühren. Im Gegensatz dazu steht touch_stop, was gefeurt wird, wenn der Avatar das Berühren beendet. Dazwischen wird beliebig oft das touch-Event gefeuert, dass besagt, dass ein Avatar das Objekt gerade berührt. Ein Avatar kann ein Objekt in SecondLife längere Zeit berühren, daher werden diese 3 Events notwendig. Im Beispiel-Skript wird auf das touch_start reagiert und in unserem Fall ein http-Request ausgeführt, der ein Beispielskript auf einem entfernten Webserver aufruft und dies per HTTP-GET erledigt.

http_response:
In diesem Handler erledigen wir endlich etwas mehr und können an LSL und dessen Funktionsumfang etwas mehr kratzen. Zuerst wird der String, der im http-Body zu finden ist, in eine Liste konvertiert, wobei das “Pipe”-Symbol als Separator identifiziert wird. Somit haben wir nun eine Liste mit den einzelnen Systemlast-Werten.
Anschließend laufen wir in einer For-Schleife über dieses Liste, wandeln die einzelnen Listenelemente in Strings (llList2String) um und schreiben diese in den Chat (llSay).

Wichtig zu wissen ist, dass Skripte einen Größenlimitierung haben, die im kompilierten Zustand greift. Diese liegt aktuell bei 64kb.

Man kann sich nun vorstellen, dass man ein PHP-Skript nutzen kann, um an weitere Informationen zu kommen oder um Informationen zu speichern. Sehr vorteilhaft ist dabei, dass man ein Webinterface erstellen kann, um diese Daten zu verwalten. Bspw. bei einem Lizenz-System. Ein externes System ist im Übrigen die einzige Möglichkeit um größere Datenmengen (mehr als 255 Zeichen) permanent zu speichern.

Zum Schluß dieses Beitrags noch einen Dank an Peter, der mich zu diesem Beitrag motiviert und mit seiner SL-Expertise unterstützt hat.

Das Interface stellt eine Möglichkeit bereit über eine Menge von Objekten zu iterieren. Ein Beispiel für eine Implementierung ist das array. In verschiedenen Projekten habe ich die Variante gesehen, dass die Objekte intern in einem Array verwaltet wurden. Sobald man über diese Objekte iterieren wollte, wurde das Array nach außen gegeben, damit man das foreach-Konstrukt nutzen konnte. Heutzutage sollte man lieber die Kapselung geschlossen lassen und das Iterator-Interface implementieren.

Als Beispiel entwickeln wir ein Objekt, dass mit einem String instanziiert wird und über das man anschließend mit foreach laufen kann. Es werden “Wörter” als einzelne Rückgabewerte betrachtet. Also wird der Eingabe-String an einem Whitespace bzw. Komma-Zeichen gesplittet. Die “WordObject”-Klasse muss nun das mehrfach angesprochene Iterator-Interface implementieren. Hierzu sind die Methoden rewind, current, key, next und valid zu implementieren.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

class WordObject implements Iterator {
 
    private $innerArray;
    private $pointer = 0;
 
    public function __construct($inputstring) {
        $this->innerArray = preg_split("/[\s,]+/",  trim($inputstring));
    }
 
    public function current() {
        return $this->innerArray[$this->pointer];
    }
 
    public function key() {
        return $this->pointer;
    }
 
    public function next() {
        ++$this->pointer;
    }
 
    public function rewind() {
        $this->pointer=0;
    }
 
    public function valid() {
        return isset($this->innerArray[$this->pointer]);
    }
}

Man kann das Objekt nun bspw. so nutzen:

1
2
3
4
5

$example = new WordObject("Hello World, this is a Iterator test");
 
foreach ($example as $key => $value) {
    echo $key . ": " . $value . "\n";
}

Dieser Code gibt dann – wie erwartet – folgende Ausgabe aus:

1
2
3
4
5
6
7

0: Hello
1: World
2: this
3: is
4: a
5: Iterator
6: test

Update und Anmerkung:
Wie in den Kommentaren angemerkt, kann man den obigen Code auch einfacher darstellen. Dafür muss das IteratorAggregate-Interface implementiert werden. Den Vorteil kann man vor allem deshalb nutzen, weil intern ein Array genutzt wird. Der Code für die vereinfachte Variante sieht so aus:

1
2
3
4
5
6
7
8
9
10
11
12

class WordObject implements IteratorAggregate {
 
    private $innerArray;
 
    public function __construct($inputstring) {
        $this->innerArray = preg_split("/[\s,]+/",  trim($inputstring));
    }
 
    public function getIterator() {
        return new ArrayObject($this->innerArray);
    }
}

Insgesamt waren die Fragen überwiegend Multiple-Choice-Fragen, die genau 1 richtige Lösung hatten. Daneben gab es noch 3-4 MC-Fragen mit mehreren richtigen Antworten und ca. 2 Fragen mit einer Freitext-Antwort.

Themenbereiche

• Grundsätzlich wurden Zusammenhänge abgefragt. Also viele Aufgaben könnte man mit “Interpreter im Kopf” beschreiben. Benötigt wird hierfür grundsätzliches Wissen über PHP an sich. Es wird also genau die Fähigkeit geprüft, die ein Entwickler beim Lesen von fremden Quellcode benötigt. Komplizierte Strukturen gab es mE nicht.
• Fragen zu Namespaces gab es sehr wenige (vielleicht 2-3)
• Die Iterator- und ArrayAccess-Interfaces wurden ausgiebig abgefragt (ca 10 Fragen). Das finde ich persönlich komisch, da für mich ein Interface nicht so ganz außergewöhnlich ist. Aber okay, die Fragen werden vielleicht zufällig ausgewählt.
• Datenbankfragen gab es auch ein paar. Diese gingen in Richtung PDO und SQL. Nicht unbedingt spezifisch auf MySQL oder ein anderes DB-Server-System. Diese allgemeinen Fragen finde ich gut.
• Fragen zu OOP waren zu erwarten und sind natürlich auch vorgekommen. Hier waren die Themen “Late static binding”, der static Modifier und die sonstigen Modifier an sich die Hauptpunkte. Ableitungen von Klassen, abstrakte Methoden und Klassen durften auch nicht fehlen. Ein guter Querschnitt über OOP. Design Patterns wurden nicht abgefragt.
• Allgemeines Wissen aus dem Bereich der Informatik wurde auch geprüft. Bspw. welche Verschlüsselungssysteme symmetrisch sind; ohne tiefer in die Materie einzugehen.

Insgesamt waren die Fragen abwechslungsreiche und der Test hat Spaß gemacht. Wer beruflich PHP entwickeln möchte sollte sich zertifizieren lassen. Der Test an sich ist günstig und wenn man tagtäglich mit PHP arbeitet, sind die Fragen ohne lange Vorbereitungszeit zu beantworten.

Möchte man das Gegenteil bewirken, gibt es den abstract-Modifier. Dieser besagt, das eine Methode unbedingt überschrieben werden muss. Auch dieser Modifier kann auf die gesamte Klasse angewendet werden. Grundsätzlich ist eine abstrakte Klasse mit abstrakten Methoden ähnlichem einem Interface. Jedoch kann eine Klasse nur von genauer einer Klasse abgeleitet sein, was bei einem Interface nicht gilt. Eine weitere Besonderheit ist die Möglichkeit in einer abstrakten Klasse die Modifier zu mischen. Es gibt also bspw. 2 abstrakte Methoden und 1 protected. Somit darf diese Methode ganz normalen Code enthalten und kann in der konkreten Klasse genutzt werden.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

 
abstract class Car {
 
     protected function turnLeft() {
          // nach links
     }
 
    /**
     * tanken
     */
    abstract public function refuel() ;
 
}
 
class DieselCar extends Car {
     public function refuel() {
          // tanke Diesel
     }
}

Die abstrakte Klasse Car bietet eine Methode um nach links zu fahren. Diese ist ausimplementiert (im Beispiel nur ein Kommentar). Daneben gibt es noch eine abstrakte Methode, um das Auto zu betanken. Das davon abgeleitete Auto muss nun die refuel-Methode implementieren.

Diese Methoden können nur von der eigenen Klasse genutzt werden und sind sowohl gegen den Zugriff von außen, als auch durch eine abgeleitete Klasse geschützt.

Nun gibt es gelgentlich das Problem, dass man bestimmte Variablen und Methoden in einer Klasse definiert und diese in einer abgeleiteten Klasse nutzen möchte, aber auch nur in dieser Klasse. Diese Methoden sollen nicht allgemein zugänglich sein. Hierfür gibt es den protected Modifier. Dieser stellt genau diese Funktionalität zu Verfügung.

Nun fehlen noch die final- und abstract-Modifier. Diese werden im nächsten Teil der Reihe beschrieben.

Als Beispiel packe ich wieder mal ein paar Autos aus:

1
2
3
4
5
6
7
8
9
10
11

class car {
    public $engine
 
    public function start() {
         $engine->start();
    }
}
 
$myCar = new Car();
$myCar->engine = null;
$myCar->start();

Wir haben nun ein Auto mit einem Motor. Da der Motor public ist, kann er auch durch Luft (oder einfach nichts) ersetzt werden. Startet man das Auto, fällt die Anwedung auf die Nase und man hat schon den beschriebenen Fall. Hätten wir einen private Modifier, könnte man den Motor durch den Zugriff von außen schützen und das sehen wir im Beitrag Teil 2.

1
2
3
4
5
6
7
8
9
10
11
12

// Message Objekt erzeugen
$message = Swift_Message::newInstance();
// Subjekt setzen
$message->setSubject("PM Test");
// Mail Text setzen (hier in Html)
$message->setBody("<i>Dies</i> ist ein <u>Test</u>","text/html");
// alternativen Mailtext hinzufuegen (hier Plaintext)
$message->addPart("Dies ist ein Test","text/plain");
// Absender setzen
$message->setFrom("sender@adres.se");
// Empfaenger setzen
$message->setTo("receiver@adres.se");

Um einen Dateianhang hinzuzufügen bietet Swiftmailer die Swift_Attachment-Klasse an. Damit lassen sich Dateien und auch Daten aus einer Variable als Anhang in ein Swift_Message-Objekt integrieren. Wenn man das obige Beispiel in der Fluent Interface Variante nutzt sieht das dann so aus:

1
2
3
4
5
6
7
8

$message2 = Swift_Message::newInstance()
    ->setSubject("PM Test 2")
    ->setBody("<i>Dies</i> ist ein <u>Test</u>","text/html")
    ->addPart("Dies ist ein Test","text/plain")
    ->attach(
          Swift_Attachment::fromPath("run.php", "text/plain")->setFilename("test.php"))
    ->setFrom("sender@adres.se")
    ->setTo("receiver@adres.se");

Die generierte Email kann man als String ausgeben. So hat man auch die Möglichkeit zu kontrollieren, ob die Mail das gewünschte Ergebnis liefern wird.

1

echo $message->toString();

Diese Mail soll nun auch noch verschickt werden. Hierfür benötigt man zuerst einen Transport. Beispielhaft ist hier der Swift_SmtpTransport vorgestellt. Interessant an dieser Sache ist, dass man den Transport bspw per Dependency Injection einbinden und somit sehr einfach wechseln kann – falls notwendig.

1
2
3

$transport = Swift_SmtpTransport::newInstance('smtphost', 25)
  ->setUsername('username')
  ->setPassword('password');

Jetzt muss man Transport und Message nur noch verbinden, um die Email auch zu versenden. Dies übernimmt die Swift_Mailer-Klasse. Der Mail-Versand kann dann mit einer einfachen Zeile realisiert werden.

1

$mailer = Swift_Mailer::newInstance($transport)->send($message);

Weitere Informationen findet man in der recht ordentlichen Doku des Swiftmailers.

Funktionsweise:
Um den Yubikey zu nutzen, gibt es mehrere Arten. Ich beschreibe nun zwei, die ich ganz praktisch finde. Hierfür benötigt man immer eine Verbindung ins Internet – ist aber bei PHP-Seiten üblicherweise gegeben (ja, im Intranet nicht ). Methode 1 nutzt den KeyGenius-Server. Dieser ist eine Passwortablage. Jedes Passwort wird über den eindeutigen Key-Identifier und ein Zufallspasswort verschlüsselt, dass bei der Ablage einmalig erzeugt wird. Jeder Key hat somit eine eigene Verschlüsselung. Auf der Client Seite benötigt man im Browser Greasemonkey. Für dieses Plugin gibt es ein Javascript, dass die Passworteingabe auf der angesurften Seite sucht und durch eine eigene ersetzt. Man gibt nun sein Login ein und anstelle des herkömmlichen Passworts einen Yubikey-OTP. Das Greasemonkey Skript betreibt jetzt im Hintergrund viel Magie. Der Key wird an den Keygenius Server inkl. Adresse und Login geschickt, dieser validiert das OTP über den yubico Server und sendet das echte Passwort zurück, dieses wird im Passwortfeld eingesetzt und ein Submit des Login Formulars durchgeführt. Der Keygenius Server liegt auch im Quellcode vor, benötigt aber Symfony. Die eigentliche Logik zu extrahieren ist aber recht simpel, so kann man ein plain-PHP5 kompatible Version basteln.
Nun die Methode 2, die etwas spannender ist und die endlich als Überleitung zum heutige PHP-Source dient. Hierbei wird eine kleine Bibliothek genutzt, die man in seine eigene Applikation einbaut. Das übliche Login Formular wird angepasst. Hier kann man entweder dem Benutzer einen Key Identifier zuordnen und diesen sozusagen als Passwort nutzen. Oder man nutzt eine Two-Factor-Authentication und hat neben dem herkömmlichen Passwort Feld noch ein zweites Passwort Feld, dass ein OTP erwartet. Für welche Variante man sich entscheidet, benötigt man auf jeden Fall eine Bibliothek, um die Validierung des Yubikeys durchführen zu können. Die von Yubico angebotene ist in PHP4 geschrieben und das passt mir natürlich nicht. Eine Alternative ist die PHP5 Variante, die in Keygenius genutzt wird. Heute stelle ich eine 3. Möglichkeit vor. Eine simple PHPMonkeys-Yubico Validierungsbibliothek.

Die Validierungs-Lib:
Für die Validierung wird ein Webservice angefragt, der zu den gegebenen GET-Parametern eine einfache Seite zurückgibt, die einer Txt-Datei entspricht. In unserer simplen Variante wird eine ID, ein OTP und ein “Nonce” benötigt. ID entspricht dem Api-Key, den man sich als Yubikey Besitzer gratis bei Yubico erstellen lassen kann. Hier bekommt man auch den Signature-Key (in Base64 codiert) – dazu später mehr. Das One-Time-Passwort ist selbstverständlich und der/die/das Nonce wird als zusätzliche Sicherheit benutzt, dass die Antwort auch zur Anfrage gehört, da dieser String vom Server einfach wieder zurückgegeben wird. Nun hört sich die ganze Geschichte recht unsicher an, aber dafür gibt es noch ein Hash-Parameter. Dabei handelt es sich um einen HMAC (Hash-based Message Authentication Code). Yubico nutzt hier einen HMAC-Sha1, das bedeutet, dass Sha1 für die Hashbildung genutzt wird. Die Nachricht, deren Echtheit man überprüfen will, ist der QueryString der GET Anfrage ohne den Hash (ist ja auch logisch). Man nutzt aber nicht einfach Sha1, weil man noch einen Signature-Key nutzen will. Dieser wird beim generieren der API-ID miterzeugt und ist das shared Secret, das sowohl bei Yubico, als auch beim Nutzer der Bibliothek bekannt ist. Der String wird in der Übertragung nirgends erwähnt und somit kann ein Angreifer die Nachricht nicht authentifizieren und somit auch nicht Parameter ändern. Weder in Richtung Server, noch vom Server zum Client.
Der Server baut sich nun aus den gegebenen Daten einen eigenen Hash und vergleicht diesen mit dem übermittelten, so kann man feststellen, wenn die Daten auf dem Weg (“Man-in-the-middle”) manipuliert wurden. Der Server antwortet nun auf eine solche Anfrage mit einem Text, der aus Key-Value-Paaren besteht die durch ein Gleichheitszeichen getrennt sind. In jeder Zeile findet sich ein solches Paar. Als Antwort erhält man natürlich einen HMAC-Sha1. Dann gibt es den Status, die Nonce und ein Timestamp. Über den Timestamp kann man die Anfrage noch an ein Zeitfenster binden. Die simple Bibliothek, die ich vorstelle hat dieses Feature (noch) nicht. Als Client kann man diese Infos nun parsen, verschiedene Vergleiche anstellen und damit die Antwort des Servers bestätigen. Dieser sendet im Status Feld ein “OK”, falls alles passt. Beliebt, vor allem beim Testen, ist der REPLAYED_OTP Status. Dies tritt auf, wenn man den Key bereits erfolgreich validiert hat und es ein zweites mal versucht. Ist ja schließlich ein One-Time-Password. Andere Status kann man der Webservice API entnehmen. Es ist eigentlich jeder Fall abgedeckt.

Die kleine Bibliothek finde man hier oder wie immer auch im SVN. Dort gibt es auch ein kleines Beispiel, wie so ein Aufruf aussieht.

Email Pass-Around:
Im Gegensatz zu dem formellen Vorgehen benötigt man beim “Email Pass-Around”-Verfahren keinen großen verwaltungstechnischen Aufwand, um das Review zu organisieren. Der Entwickler schickt einfach die Codeänderungen per Mail an alle Kollegen. Diesen Vorgang kann man mit einem Commit-Hook automatisieren. Vorteil bei diesem Vorgehen ist, dass jeder Entwickler, der an dem Projekt arbeitet, den Code anschauen und beurteilen kann. Das Ganze kann durchaus asynchron passieren, somit kann das Review zu einem passenden Zeitpunkt durchgeführt werden. Nachteil ist, das im “worst case” niemand den Code anschaut. Hier muss unter den Entwicklern eine entsprechnde Disziplin herrschen. Auf der anderen Seite ist ein Entwickler normalerweise daran interessiert ein bestmögliches Produkt zu erstellen.

Peer Reviews:
Möchte man sicherstellen, dass Code Reviews durchgeführt werden, aber den Overhead eines formellen Vorgehens vermeiden, bietet sich ein Peer Review an. Hierbei besprechen 2 Entwickler eine Codepassage. Einer der Entwickler sollten den Code programmiert haben. Die Länge des Codes is in der Regel zwischen 100 und 300 Zeilen. Für diese Codemenge muss man ca. 1 Stunde einplanen. Wichtig ist, dass man nicht von einer Lehrer-Schüler Beziehung ausgeht, sondern sich beide Entwickler als gleichberechtigt verstehen. Problem bei Peer Reviews ist, dass diese nicht “von oben” gesteuert werden können. Wenn man dies trotzdem versucht, wird ein solches Vorgehen schnell zu einem Muss und wird nur noch halbherzig duchgeführt, was dann weder die Verbreitung des Wissens beschleunigt, noch die Codequalität verbessert.

Fazit:
Aus persönlicher Erfahrung kann ich sagen, dass in einer angenehmen Atmosphäre Peer Reviews am meisten bringen und dabei auch noch Spaß machen. Bei uns hat sich eingebürgert die Peer Reviews in einem kleinen Konferenzraum durchzuführen. So können beide Entwickler auf einem Beamer oder großem Monitor den Code anschauen und bei der Diskussion fühlt sich auch kein Kollege gestört. Eine Tasse Kaffee gehört ebenfalls zu einem Review. Anmerkungen werden gleich in den Code als TODO geschrieben und zeitnah angegangen.

Email Pass-Around nutzen wir schon seit Jahren und dieses Verfahren funktioniert relativ gut und hat schon den ein oder anderen Patzer im Code aufgedeckt. Die Asynchronität ist hier ein sehr spannender Aspekt. Und wer seine Firmenmails aufs Handy bekommt, kann überall mal schauen, was am Code gearbeitet wird – sofern man denn will.