php-books.de

Leider sieht man immer wieder, dass völlig sorglos mit Usereingaben oder anderen Parametern, die an ein Skript übergeben werden, umgegangen wird. Selbst wenn man sich die größte Mühe gibt, wird man nie eine hundertprozentig sichere Anwendung haben, solange Userdaten verarbeitet werden müssen. Allerdings sieht man oft genug Skripte, in denen überhaupt keine Validierung stattfindet. Natürlich lässt sich eine Anwendung auf diese Weise um ein Vielfaches schneller fertigstellen, dies erkauft man aber mit einer hohen Anfälligkeit für Angriffe oder auch nur für Fehler.

Ein Grund, warum man derart ungesicherte Skripte immer wieder antrifft, ist wohl auch der leichten Erlernbarkeit von PHP zuzuschreiben. Die Lernkurve ist recht flach und so kann man mit relativ wenig Kenntnissen schon recht beeindruckende Ergebnisse abliefern. Wie es tatsächlich um den Code bestellt ist, sieht der Anwender oder schlimmer noch, der Auftraggeber oft gar nicht.

Read the rest of this entry »

Seit einiger Zeit wird PHP im Bundle mit dem Datenbanksystem SQLite ausgeliefert. Anders als MySQL ist SQLite kein Datenbankserver, somit wird beim Betrieb auch kein eigener Prozess für SQLite ausgeführt. Stattdessen handelt es sich um eine Bibliothek ohne externe Abhängigkeiten, die direkt im PHP-Prozess ausgeführt wird. Daher gibt es hier auch keinen Kommunikationsweg zwischen PHP und der Datenbank. Datentransfers innerhalb eines Prozesses sind immer schneller, als Interprozess-Kommunikation beziehungsweise die Kommunikation zwischen unterschiedlichen Servern. Also ein klarer Vorteil für SQLite. Auf der anderen Seite kann die Datenbank auf diese Weise so natürlich nicht auf einen dedizierten Server ausgelagert werden, was bei zunehmender Last zu einem Problem werden kann.

Read the rest of this entry »

Eine weitere magic-Function ist die __autoload() Funktion.

Sie ermöglicht das automatische Nachladen von Dateien und soll den Einsatz von inlcude() und require() ablösen. Die Voraussetzung für den Einsatz von __autoload() ist eine objektorientierte Programmierung mit einer klaren und stringenten Strukturierung.

Wird ein Objekt einer Klasse instanziiert, welche nicht eingebunden ist, wir die __autoload()-Funktion aufgerufen, gleiches gilt für extends und implements. Als Parameter bekommt Sie den Klassennamen übergeben.

function __autoload($s_klassenname)
{
    require($s_klassenname.'php');
}

Aus dem übergebenen Klassennamen werden nun entsprechend der Programmierung der Funktion der Pfad und der Name der zu inkludierenden Quelldatei genieriert und diese eingebunden.

Hierbei muss der Programierer dafür Sorge tragen, dass dies nicht zu unerwünschten Ergebnissen führt, so kann zum Beispiel bei mangelhafter Prüfung auch eine URL übergeben und so eine Datei von einem fremden Server inkludiert werden, was eine nicht unterhebliche Gefährdung der Webanwendung nach sich zieht.

Hier sind also die üblichen Vorsichtsmaßnahmen zu treffen: Gültigkeitsprüfung mit Regulären Ausdrücken, Existenzprüfung z.Bsp. mit file_exists() und Kontrolle, ob die einzubindende Datei auch die Klassendefinition enthält class_exists().

try
{
    if(FALSE === RegEx)
    {
        throw new Exception("Klassenname $s_klassenname ist ungültig");
    }
    else
    {
        require_once($s_klassenname);
    }
}

catch(Exception $e)
{
    die($e->getMessage());
}

Diese Art der Programmierung erfordert jedoch ein hohes Maß an Organisation, durch unbedachtes Bennenen von Dateien und Klassen kann die Fehlersuche deutlich erschwert werden. Außerdem muss darauf geachtet werden gewissen Konventionen beim Anlegen und Verwenden von Pfaden eingehalten werden, die jedem Programmierer in einem Projekt bekannt sein müssen. Auch in Hinblick auf die möglichen Sicherheitsimplikationen sollte die Verwendung von __autoload() gut überdacht werden.

Manchmal kommt man mit utf8_decode nicht weiter, zum Beispiel dann, wenn man nicht weiß, in welchem Format die Daten angeliefert werden, und diese sowohl in UTF8 als auch in ISO-8859-1 hereinkommen können. Es passiert zum Beispiel manchmal bei Eingabefeldern in Webseiten, dass ein Browser UTF8-Daten schickt, obwohl die Seite in ISO ausgeliefert wurde.
Würde man nun einfach alle hereinkommenden Daten mit utf8_decode bearbeiten, käme es zuweilen zu seltsamen Ergebnissen.

Da ist es manchmal einfach sinnvoller mit”Suchen und Ersetzen” zu arbeiten.

Dieses kleine Codesnippet does the trick:

< ?php

       $trans = array("ä" => "ä", "Ä" => "Ä", "ü" => "ü", "Ãœ" => "Ü", "ö" => "ö",
      "Ö" => "Ö", "ß" => "ß");
      $string = strtr($string, $trans);
?>

So wird sichergestellt, dass am Ende auch wirklich die Umlaute herauskommen, die man haben wollte.

Die __toString Methode wird immer dann Aufgerufen, wenn man ein Objekt mit echo oder print ausgibt. Was die Funktion machen soll muss man dann natürlich selbst implementieren. Ab PHP 5.2.0 erfolgt dieser Aufruf in jedem Stringkontext (z.B. in printf() mit %s Platzhalter) aber in keinem der anderen Typenkontexte (z.B. mit dem %d Platzhalter). Ebenfalls ab PHP 5.2.0 bewirkt die Umwandlung eines Objekts ohne __toString Metohde in einen String einen Fehler der Klasse E_RECOVERABLE_ERROR.

Bsp:

 <?php
    class car
    {
        public function __toString()
        {
            return "This is a nice car\n";
        }
    }

     $fiat = new car;

     echo $fiat;

?>

>This is a nice car

Ohne eine __toString() Methode gibt PHP nur die Object ID aus, womit sich nicht wirklich viel anfangen lässt.

Magische Funktionen wurden als ein Teil des verbesserten Objekt-Models in PHP 5.1 eingeführt. Sie werden magisch genannt, weil sie nicht direkt aufgerufen sondern durch andere Aktionen aktiviert werden. Bei der Einführung von PHP 5.1 gab es folgende magische Methoden:

__construct, __destruct, __toString, __autoload, __call, __clone, __get, __set, __sleep, __wakeup, __unset und __isset

Manche dieser magischen Methoden sind wichtig, andere stellen jedoch nur eine nette “Beigabe” dar. Während einige Methoden ziemlich selbsterklärend und leicht handhabbar sind, benötigen andere eine eingehendere Betrachtung.

__construct

und

 __destruct

Während in PHP4 der Konstruktor einer Klasse noch den gleichen Namen, wie die Klasse selbst haben musste, kann in PHP 5.1 die magische Methode

__construct()

verwendet werden. Im Endeffekt war damit der alte Konstrukter auch schon “magisch”, er wurde ja automatisch aufgerufen, wenn man ein neues Objekt der Klasse erstellt hat. Insofern ist es eher eine logische Vereinheitlichung, den Konstrukter durch die zwei Unterstriche auch als magische Funktion zu kennzeichnen. Zudem kann man jetzt den Namen der Klasse einfach ändern, ohne den Konstruktor anpassen zu müssen. Außerdem erlaubt er ein leichteres Aufrufen des Parent-Konstruktors einer abgeleiteten Klasse -

parent::__construct()

Der Destruktor stellt das Gegenstück zum Konstruktor dar. Er ist dafür zuständig, dass beim Löschen eines Objektes gewissen Aufräumarbeiten, wie das Schließen von Dateien oder Datenbankverbindungen durchgeführt werden.
Zwar ist PHP sehr sorgsam beim Aufräumen und schließt beim Beenden von Skripten selbständig offende Deskriptoren, jedoch kann man durch explizites Ausprogrammieren weitere Arbeiten verrichten lassen, die ausführt werden sollen, wenn ein Objekt den Speicher verlässt.

Ein Pattern beschreibt ein Problem im Software-Design und bietet zugleich die Lösung. Mit Lösung ist hier jedoch nicht das Verfahren gemeint, welches einem die vielen Cookbooks anbieten. Ein Design-Pattern ist nicht die Cut and Paste Lösung für ein Problem, sondern es zeigt einen standardisierten Lösungsansatz für immerwiederkehrende Problemstellungen auf. Auch wenn man Beispiellösungen finden mag, so geht es doch um das Konzept der Lösung. Patterns folgen meist gewissen Kern-Prinzipien, was das Design angeht. Das Verständnis dieser Prinzipien hilft nicht nur bei der Analyse der Patterns sondern auch bei ihrer Adapation auf die täglichen Programmierungen.

Allgemein gesprochen ist ein Pattern ein Entwurfsmuster, eine Lösungs-Schablone für ein wiederkehrendes Entwurfsproblem. Es ist somit eine immer wieder zu verwendende Vorlage für bestimmte Problemstellungen.

Entwurfsmuster lassen sich in Klasseneinteilen:

• erzeugende Muster
• strukturelle Muster
• Verhaltensmuster
• weitere Muster

Auch in PHP setzen sich Design-Patterns immer mehr durch. Dies gilt zumindest für den Bereich der objektorientierten Programmierung.

Einige der bekannteren Patterns:

• Singleton Pattern
• Factory Method Pattern
• Abstract Factory Pattern
• Observer Pattern
• Visitor Pattern
• Command Pattern

Um Patterns zu verstehen, sollte man mit der objektorientierten Programmierung bereits gut vertraut sein.

Ein ganz trivialer Grund, warum Patterns so beliebt sind, ist die simple Tatsache, dass jeder Programmierer früher oder später auf die selben Probleme trifft, wie tausende andere Programmierer vor ihm. Wie auch der Autobauer nicht jedes Mal das Rad von neuem erfindet, kann auch jeder Programmierer vom Wissen seiner Vorgänger oder Mitstreiter profitieren. Neben der Lösungsvorlage für gewisse Probleme bieten Patterns darüberhinaus eine Art gemeinsamer Sprache unabhängig von der Programmiersprache selbst.

Daher denke ich, dass ich mich hier bei Gelegenheit mehr über diese faszinierende Facette der Programmierung auslassen werde.

Wenn man ein SVN-Repository umzieht, dann ändert sich in der Regel auch die URL zu diesem. Möchte man nun aber wie gewohnt die Dateien auschecken, muss man dem SVN erstmal die neue Location des Repositorys mitteilen.

Dies geschieht mit dem Befehl:

svn switch --relocate https://altesrepository/trunk  http://neuesrepository/trunk

Möchte man lediglich zu einem anderen Branch im Repository wechseln verwendet man:

svn switch https://altesrepository/trunk http://neuesrepository/trunk
Eine Warnung aus dem Handbuch:

Vorsicht mit dem Schalter

--relocate

. Wenn man sich bei der URL verschreibt kann man schnell mit einer Arbeitskopie enden, die komplett funktionsuntüchtig und gewöhnlich nur schwer wieder herzustellen ist. Es ist wichtig zu unterscheiden, wann man  –relocate verwenden soll und wann nicht.

Faustregel:

• Wenn die Arbeitskopie einen neuen Speicherort innerhalb des Repositorys bekommt, benutzt man nur svn switch.
• Bleibt das Repository-Verzeichnis das gleiche, aber der Ort des Repositories ändert sich wird svn

  switch –relocate

  verwendet.

Testen

Wenn nun scheinbar alles geklappt hat, dann möchte man ja sicherheitshalber erstmal testen, ob alles richtig funktioniert, bevor man sich unter Umständen ein Live-System oder auch nur ein Test-System zerschießt. Leider gibt es soweit ich das herausfinden konnte keine Mögklichkeit, zum Beispiel ein update –test oder ähnliches auszuführen.

Update ist jedoch eigentlich nur ein Alias für svn merge -r BASE:HEAD

Man kann also einfach in das entsprechende Verzeichnis wechseln und mit

svn merge --dry-run -r  BASE:HEAD .

sich anschauen, welche Dateien upgedatet werden würden und ob das überhaupt alles richtig funktioniert. Der letzte Punkt in der Befehlszeile ist übrigens wichtig, da er das Zielverzeichnis (in diesem Fall also das aktuelle) angibt. Wenn nun alles ordnungsgemäß verlaufen ist, sollte man auf der sicheren Seite sein.

Kleine Merkhilfe

string chr ( int $ascii )

Gibt einen Ein-Zeichen-String zurück, der dem angegebenen ascii -Wert entspricht.

Um nun ein € Zeichen zu erhalten muss man lediglich chr(128) ausgeben.

Wer gerne mal über den Tellerrand schaut und andere Sachen ausprobiert, aber nicht die große Lust verspürt, sich erstmal eine komplette Entwicklungsumgebung einzurichten findet mit Try Ruby eine nette kleine Möglichkeit Ruby unverbindlich im Webbrowser zu “testen”.