Website Framework

Einsatzgebiete

Das Framework kommt u.A. bei dieser Website zum Einsatz. Wie der Name bereits sagt, lässt sich des Einsatzgebiet nicht genau eingrenzen. Designed wurde es für Applikationen mit Workflow. Das Shop-Plugin sowie das CRUD-Plugin und die darauf basierenden soweit realisierten Applikationen deuten die Vielfalt der Einsatzmöglichkeiten an. Wegen einiger der u.g. innovativen Konzepte empfiehlt es sich für Multi-User und -Mandantensysteme mit Zugriff auf sensible Daten. Tatsächlich wird es so auch schon eingesetzt. Bei der Eignung für Einsatzgebiete gibt es ansonsten Überschneidungen mit Symfony, Drupal, dem Zend Framework, Magento und JBoss.

Merkmale

  • Modern (Objektorientiert, php5, MVC).
  • Schlank, der Unterschied im Quellcode-Umfang zu den o.g. Frameworks ist geradezu grotesk.
  • Der Transaktionsserver gewährleistet die Anbindbarkeit an externe Applikationen.
  • Multi-Domain-fähig. Die Homepage einer Domain kann beliebig im Menü plaziert werden und gilt rekursiv auch für alle Kinder-Seiten des Menüpunkts. Domain-übergreifende User-Sitzungen sind mit Standard-Web-Technologie realisiert. Bei Browsern mit eingeschalteten Cookies wird dies durch die sog. Cookie-Synchronisation (s.u.) gewährleistet.
  • Durchgängige https Verschlüsselung, die im Menü-Baum selektiv und rekursiv, z.B. für eine Domain, an- bzw. abgeschaltet werden kann.
  • Unterstützt gleichzeitig Desktop-User (auch mit NoScipt-Browser-Plugin), Tablets und Handies.
  • Der Bedienkomfort ist in allen o.g. Konstellationen die Referenz für andere Frameworks.
  • Uneingeschränkt lauffähig in multiplen Browser-Fenstern bzw. -Tabs.
  • Volltextsuche (bei dieser Website in Arbeit) mit Treffer-Anzahl und -Listen pro Item im Menübaum.
  • Die Hauptmenüpunkte speichern jeweils die zuletzt gewählten Untermenüpunkte. Es werden sozusagen Browser-Tabs simuliert. Dies funktioniert sogar nahezu uneingeschränkt mit unsynchronisierten Cookies multipler Domains.
  • Multiple Step Formulare sind vorbildlich realisiert.
  • Der gesamte Workflow funktioniert ohne HTTP-Redirects, Javascript und ggfs. auch ohne Cookies. Die Vorteile:
    • User mit NoScript-Browser-Plugin sind willkommen,
    • Die Webseiten laden im Gegensatz zu Javascript-lastigen auch dann noch schnell, wenn der Rechner des Users an den Grenzen seiner Belastbarkeit operiert,
    • Javascript kann bedenkenlos für andere Zwecke eingesetzt werden, ohne dabei Gefahr zu laufen, den Workflow zu beeinträchtigen.
  • Konfiguration des Menübaums und des Verhaltens der Seiten über XML.
    Websites mit diesem Framework bestehen aus der Menü-XML-Datei, statischen HTML-Seiten und dem generischen Framework. Scripte mit Workflow können ggfs. zusätzlich eingerichtet und ins Menü-XML eingebunden werden.
  • PlugIn-fähig (z.Z. verfügbar: Shop-Plugin und CRUD-Plugin).
  • HTML-Tabellen- und Formular-Generator von Dipl.-Informatiker Martin Hupf.
  • Layout (nicht vom Daten-Rücker implementiert) mit
    oder bootstrap

Innovative Konzepte

Intrusion Detection als Design Paradigma


Das Filtern von CGI-Variablen ist das Mittel der Wahl zum Unterbinden von Cross Site Scripting.
Verwendete CGI-Variablen müssen im Framework deklariert werden, bevor deren Werte Eingang in die Script-Verarbeitung finden können. Dabei werden u.A. Default Werte gesetzt, der Ziel-Datentyp festgelegt und Wertebereiche definiert, bei Arrays für alle Dimensionen.

Datentyp und - sofern möglich - Wertebereich werden im CRUD-Plugin automatisiert via Transaktionsserver aus der Datenbank ausgelesen. So braucht man sich um die Validierung zumindest bei Aufzählungs-Typen sowie numerischen und Datums-Feldern nicht mehr zu kümmern. Dies klappt auch bei Multiple-Choice-Feldern, die über n:m Tabellen realisiert sind.

Mit Hilfe dieser Meta-Information über verwendete CGI-Variablen klappt das Intrusion Detection weitaus treffsicherer als bei nachträglich aufgestülpten Systemen. Unautorisierte CGI-Zugriffe - z.B. bei Wertebereichs-Konflikten oder wenn unbekannte Variablen ins System eingeschleust werden sollen - werden beim Einlesen der CGI-Variablen zuverlässig erkannt und detailliert protokolliert.

Gültigkeitsbereiche von Session-Variablen relativ zu Menübaum-Items


Session-Variablen müssen genauso deklariert werden, wie CGI-Variablen, und zwar in allen Scripten, in denen schreibend auf sie zugegriffen wird. Entweder für sich genommen oder typischerweise und ggfs. zusammen mit einer zugehörigen CGI-Variable gleichen Namens. Die Session-Variablen stehen dann gemäß ihrem Gültigkeitsbereich in allen Scripten der Applikation jemeils im zweidimensionalen Array 'session_vars' zur Verfügung.

Neben den Gültigkeitsbereichen

  • Session - in der gesamten Applikation
  • Script - nur im Script selbst

stehen folgende Gültigkeitsbereiche in Relation zum Menüpunkt des jeweiligen Scripts bereit:

  • Branch - im zugehörigen Hauptmenüpunkt und dessen Untermenüpunkten (ist für die Tabreiter-Memory-Funktion des Frameworks implementiert worden)
  • Siblings - in allen Scripten der Geschwister im Menü-Baum (ist für Multiple Step Formulare implementiert worden)
  • MenuItemScripts - in allen Scripts, die sich einen Menüpunkt teilen (z.B. das List- und das Edit-Formular zum Bearbeiten von z.B. Kunden im CRUD-Plugin)
  • URN - nur im Script selbst und zwar nur, wenn der gleiche Seiten-Identifikator wieder kommuniziert wird

Wenn ein Menüpunkt bzw. Sub-Baum im Baum verschoben wird, behalten die User-Sessions dabei volle Gültigkeit.
Die konsequente Anwendung dieser Gültigkeitsbereiche

  • schafft Sicherheit, da Session-Daten nur den Scripten bekannt gemacht werden, die sie brauchen,
  • ermöglicht, daß Scripte sich untereinander austauschen, indem man gezielt festlegt, welche Scripte sich die Werte von Session-Variablen miteinander teilen und
  • ermöglicht die Wiederverwendung von Session-Variablen-Namen in multiplen Scripten, ohne daß sich diese dabei gegenseitig die Werte überschreiben.

Script-interne Weiterleitungen


Ein modernes Framework ist ohne Weiterleitungen nicht möglich. Im Gegensatz zu anderen finden die Weiterleitungen bei diesem Framework aber intern statt, ohne dabei HTTP oder gar Javascript zu bemühen. Dies ist ein zentraler Kritikpunkt des Daten-Rücker an vielen anderen Frameworks. Dieses Framework hangelt sich via CGI von Script zu Script. Daß beim Ausliefern einer Webseite die Kontrolle zwischenzeitig niemals wieder an den Browser zurückgegeben wird, bedeutet ein Plus an Sicherheit und Performanz.

Außerdem kann so - anders als bei nahezu allen anderen Frameworks - ein punktgenaues Tracking z.B. für Google Analytics gewährleistet werden. Das Ergebnis wird nicht durch zig HTTP-Weiterleitungen, die der User nur kurz aufflackernd oder garnicht sieht, verfälscht. Darüber hinaus ist das, was bei der Auswertung des Google-Tracking angezeigt wird, nicht nur genau das, wohin die User geklickt haben, sondern auch das, was sie gesehen haben.

Monolithische, mutierende Seiten-Objekte


Begriffe, bei denen mancher gestandene Softwareentwickler die Stirn runzelt. Aber es ist bei näherer Betrachtung ein durchaus sauberes und mächtiges Konzept. Bei diesem Framework gehören monolithische Objekte zum Design-Paradigma, denn mehr braucht es nicht, um in den vollen Genuss der Überlegenheit objektorientierter Programmierung zu kommen und deren Auswüchse werden so vermieden.

Nahezu alle Klassen von Seiten-Objekten sind in einem Objekt vereint (bis auf z.B. die Model-Komponente mit dem Transaktionsserver sowie HTML-Tabellen- und Formular-Generator). Für ein Seiten-Objekt werden pro Einsatzzweck bzw. Script nur die jeweils benötigten Klassen hierarchisch aufeinander gestapelt. Es gibt in der Vererbungshierarchie wenige (<5) "fest verdrahtete" Basis-Klassen und solche mit variablem Parent, die bedarfsweise in der Vererbungs-Hierarchie eingeflochten werden. Zu den fest verdrahteten Basis-Klassen zählt die 'site'-Klasse, ein "leere" Klasse, die es erlaubt, nah an der Ursprungs-Klasse spezifische Funktionalitäten einzubauen.
Die Mutations-Methaper aus der Biologie hinkt etwas. Ein weiterleitendes Seiten-Objekt löscht sich selbst, bevor ein einziges, anders strukturiertes Folge-Seiten-Objekt aufgebaut wird. Das hält den Speicherbedarf von Scripts mit mehreren Verarbeitungsschritten stets niedrig. Systemmeldungen, die Verbindung zum Transaktionsserver und andere Script-spezifisch festgelegte Objekt-Variablen leben im Folge-Objekt weiter.

Motivation

  • Diese Art der Integration von zusätzlichen Funktionalitäten rückt den zugehörigen Code ins Zentrum des Frameworks und eröffnet unmittelbar Eingriffsmöglichkeiten in allen Verarbeitungsschritten von Seiten-Objekten.
  • Wohl in keinem anderen Framework hat der Begriff "Plugin" eine tiefere Bedeutung, als in diesem. Jede zusätzliche Klasse ist ein Plugin mitten in das monolitische Seiten-Objekt hinein. Das Shop-Plugin und die soweit realisierten auf dem CRUD-Plugin basierenden Applikationen zeigen eindrucksvoll die Stärken dieses Konzepts.
  • Es gibt so gut wie keine leeren Funktions-Rümpfe, "Interfaces" sind ein Fremdwort und der Aufwand für das Erzeugen und Verwalten periphärer Objekte entfällt. Dies ist u.A. ein Grund für die Schlankheit des Frameworks.
  • Funktionalitäts-Blöcke können sehr gut auf Klassen-Quell-Dateien verteilt werden. Es entsteht gut wartbarer Code geringer Komplexität.
  • Es fällt dem Daten-Rücker leichter, ein einziges, monolitisches Objekt im Kopf zu behalten, als zig Objekte, die zueinander in Beziehung stehen.

Nachteile von Klassen mit variablem Parent

  • Beim Design der Vererbungshierarchie muß beachtet werden, daß es nicht vorkommen darf, daß eine solche Klasse im Laufe der Abarbeitung eines Scripts mit internen Weiterleitungen (s.o.) mal den einen, mal den anderen Parent hat, denn dies würde zu einem Laufzeitfehler führen. Heterogene Parents wären eine Verletzung von Grundprinzipien objektorientierter Programmierung. Dies muß (und kann) in diesem Framework durch Objekt-übergreifende Planung der Vererbungshierarchie vermieden werden.
    Wenn aber das Kind in den Brunnen gefallen ist und es bei einer Websites doch vorkommt, daß
    • eine nach diesem Design-Paradigma mehrfach eingebundenen Zusatzfunktionalitäts-Klasse heterogene Parents hat und
    • in mehr als einer dieser Konstellationen im Zuge einer Script-internen Weiterleitung aufgerufen wird,
    bleiben als Auswege,
    • Kopien von Klassen-Quelldateien unter anderem Klassen-Namen anzulegen,
    • zur Laufzeit anders benannte Clone-Klassen über Serialisierung und Deserialisierung zu erzeugen oder aber
    • doch auf den in diesem Framework eigentlich missbilligten HTTP Redirect auszuweichen.
  • In der Entwicklungsumgebung geht Komfort verloren, weil bei diesen die Vererbungshierarchie nicht eingelesen werden kann.
    Das Einlesen ist aber durch die Art der Implementierung nicht prinzipiell unmöglich und es ist nicht auszuschließen, das zukünftige Versionen von Entwicklungswerkzeugen in der Lage sein werden, die Vererbungshierarchie von Klassen mit variablem Parent einzulesen.

Identifikator-Anonymisierung statt -Verschlüsselung


Diese Methode ist das Mittel der Wahl, wenn es darum geht, sensible Daten zu schützen.
Es widerspricht aber dem Prinzip, daß eine Ressource immer unter der gleichen URL zugänglich sein sollte und kommt daher wohl nur für geschlossene Benutzergruppen in Frage.

Die Datenbank- bzw. Script-internen IDs und Feldnamen werden nach außen verborgen. Stattdessen werden durchnumerierte Ids und Feldnamen - pro HTML-Seite jeweils erneut bei 0 beginnend - zum Browser kommuniziert. Die Verwendung von multiplen Tabs bzw. Browserfenstern ist dabei berücksichtigt und explizit vorgesehen.

Die Anonymisierung erstreckt in alle Verästelungen von CGI-Variablen bis hin zu z.B. Werten von DropDownBox-Items. Sie funktioniert dabei vollkommen automatisch, d.h. es bebarf keines zusätzlichen Programmieraufwands in den spezifischen Seiten-Klassen-Dateien.

Das Feature ist z.Z. nur im CRUD-Plugin realisiert. Zum Debugging kann es auch abgeschaltet werden.
Die anonymen, durchnumerierten Items werden serverseitig mittels in den Session-Daten vorgehaltenen Menüpunkt-spezifischen Umschlüsselungstabellen in echte Ids und Feldnamen gewandelt.

So wird Hackern das Reverse-Engineering erschwert und vor allem zuverlässig verhindert, daß in Multi-User- und -Mandantensystemen via Zugriff auf fremde IDs unauthorisierte Daten zugegriffen werden können. Semantische Zugriffskontrollen sind dagegen fehleranfällig und verschlüsselte IDs können niemals zu 100% sicher sein.