Jegliche Art von Software wurde von Menschenhand geschaffen. Menschen neigen dazu Fehler zu begehen, daher kann eine Software auch nur so gut sein wie ein Mensch sie macht. Der Mensch muss aus diesem Grund seine eigenen Fehler und Schwächen (er-)kennen um diese zu verhindern bzw. zu beseitigen. Auch Webseiten, welche durch Menschen mit dem CMS VIO.Matrix erstellt wurden, können derartige Schwächen aufweisen - der folgende Fachbeitrag lenkt die Aufmerksamkeit der Programmierer zurück auf das Wesentliche was hinter jeder Webseite steckt: von Menschenhand geschaffener Code.
Innerhalb von VIO.Matrix existiert eine strickte Trennung von Layout, Funktion und Inhalt. Die ersten beiden Punkte werden durch einen Programmierer im VIO.Matrix Administrator hinterlegt. Für den Inhalt ist der Redakteur der Webseite mit Hilfe des Content-Managers verantwortlich.
Das Design einer Webseite wird bereits vor der Integration in VIO.Matrix von einem Designer fest vorgegeben. Das Ergebnis sollte valider HTML- und CSS-Code sein der auch ohne ein CMS verwendet werden könnte. Dieses Design wird in die Layouts des VIO.Matrix Administrators eingefügt und dort in seinen Bestandteile zerlegt, so dass ein VIO.Matrix-basiertes Web entsteht (siehe auch Einsteiger-Tutorials).
Eine Funktion einer Webseite wäre z.b. ein Kontaktformular. Dieses könnte man ohne eine dynamische Verarbeitung der eingegebenen Inhalt nicht ins Internet stellen. In VIO.Matrix haben oft auch Menüstrukturen eine besondere Funktion. Z.B. kann man Untermenüpunkte eines Hauptmenüpunktes erst dann sichtbar machen, wenn der Besucher sich innerhalb des Hauptmenüpunktes befindet. Die meisten Funktionen sind erst ab Lizenzen mit enthaltenem CIS, also ab Content Creator Business, möglich.
Anders als bei freier Software bei der jeder Interessierte Einblick in die Programmierung hat, kann man dies bei VIO.Matrix-Projekten nur als Programmierer des jeweiligen Projektes. Dadurch fällt es potentiellen Angreifern schwerer die Lücken zu entdecken die sich in der Programmierung auftun.
Wendet man als Webentwickler eine Technik nicht richtig an, kann dies durchaus sehr weitreichende Folgen haben. Im einfachsten Fall bewirkt es lediglich eine "Änderung" am Design, vielleicht führt auch ein Link nicht dorthin wohin er zeigen sollte. Gravierender ist jedoch, wenn beim Aufruf einer Webseite dem Besucher plötzlich MySQL-Code, vielleicht sogar die Zugangsdaten angezeigt werden. Durch derartige Fehler kann der Datenschutz wie auch die Sicherheit einer Webseite untergraben werden.
VIO.Matrix kann jegliche Inhalte über eine Pipeline in ein nahezu beliebiges Ausgabeformat bringen. Ein Layout mit CSS-Code sollte z.B. eine andere Pipeline erhalten als ein Layout mit HTML-Code. Wird diese Konfiguration nicht vorgenommen kann es passieren, dass die Browser eine Datei mit CSS-Code nicht als solche lesen, weil der Content-Type der Datei nicht dem entspricht, und die Seite somit fehlerhaft anzeigen.
Beispiel für den Serialisierer einer CSS-Pipeline:
Hier wird als Content-Type text/css gesetzt - dadurch erkennen Browser, dass die Datei CSS-Code enthalten sollte und interpretieren diesen auch entsprechend.
Gleiches gilt auch für jegliche andere Dateiformate wie z.B. HTML-, XML-, PDF- oder CSV-Dateien.
Übrigens: erstellt man ein Projekt auf Basis des dynamischen VIO.Matrix CIS von Grund auf neu kann man das verwendete CGI auf dem Server erst verwenden, wenn dem obersten Ordner ein Layout zugeordnet ist, welches auch Inhalte ausgibt. Ein kleiner Text a la "Hallo Welt" in diesem Layout hilft hier sofort weiter.
Die Verarbeitung von checkbox- oder radio-Formularfelder deren Inhalte als Sitzungsvariablen gespeichert werden wie z.B.
würde mit VIO.Matrix nicht funktionieren, da der Wert des Feldes (value) nicht in der Sitzung gespeichert wird. Die Lösung ist simpel: man setzt zuvor mit kd_0001 den Namen des Feldes für die Sitzung um dieses mit einem Null-Wert zu initialisieren. Beispiel:
Natürlich müsste die Zahl 0001 entsprechend der Nummerierung der Felder auf einer Seite erhöht werden.
Weiterhin muss man wie auch bei jeder anderen Webprogrammiersprache darauf achten, dass über Formulare eingegebene Zeichenketten nicht die Programmierung der Webseite untergraben. Zu diesem Cross-Site Scripting gibt es auch bereits einen Fachbeitrag in dem die Ursachen wie auch die Möglichkeiten zur Umgehung dieser potentiellen Risiken beschrieben werden.
Auf Formulare bezogen ist die Lösung recht einfach: jegliche Formulareingabe muss bei der Ausgabe auch maskiert werden. D.h. in Formulareingabefeldern muss die codec-Option xmlmask verwendet werden:
Wenn durch den Benutzer erzeugte Variableninhalte in MySQL eingetragen werden, müssen diese ebenfalls maskiert werden um keinen MySQL-Fehler zu erzeugen. Beispiel:
Links, welche über die anchor.dll gesetzt werden, benötigen vor der Ausgabe im Layout:
Ein negatives Beispiel:
Ein positives Beispiel:
Hinweis: dieses positive Beispiel sollte den HTML-Tag <a> auch um die Attribute title und/oder target ergänzen können. Da nicht jeder Link der über eine anchor.dll erzeugt wird auch diese Attribute konfiguriert hat muss man diese mit Hilfe von Bedingungen einbauen:
Variablen sollten genau wie bei PHP oder anderen Programmiersprachen innerhalb der Webseite nur ein Mal verwendet werden. Daher sollte man sich zu Beginn eines Projektes Klarheit über die Nomenklatur für Variablennamen im eigenen Projekt schaffen.
Formularvariablen, die eine Texteingabe durch den Redakteur ermöglichen, sollten vorausschauend immer mit einem Sprachkürzel belegt sein. Beispiel:
Dadurch ist es später einfach möglich für 2 oder mehr Sprachen neue Eingabefelder anzulegen ohne die komplette Integration erneuern zu müssen. Analog zum obigen Beispiel wären der Name für das englischsprachige Feld "en_text", für spanisch "es_text" usw.
Daneben gibt es auch noch SP-Variablen die in einem Seitenaufruf durchaus mehrfach verwendet werden könnten. Bestes Beispiel sind die eindeutigen IDs für #SPLIT oder #SYNDICATE. Bei diesen sollte man sich ebenfalls von vornherein klar sein wie man diese einheitlich schreibt. Ein positives Beispiel:
In diesem Beispiel wird die SP-Variable synid hochgezählt bevor ein neuer SYNDICATION-Block verwendet wird. Das hat den Vorteil, dass eine Syndication-ID nur ein einziges mal verwendet wird - genau wie es VIO.Matrix erfordert. Direkt nach dem SYNDICATION-Block kann man zur Verarbeitung der Ergebnisse dieses Blocks auf die verwendete Syndication-ID zugreifen. Gleiches gilt auch für #SPLIT und #DBUPDATE.
Macht man dies nicht könnten an völlig unerwarteten Stellen des Webs Inhalte und Daten auftauchen. Dadurch wäre der Inhalt, im schlimmsten Fall auch das Design der Seite verfälscht, was den Besuchern nicht gerade gefallen würde.
Von enormer Bedeutung ist auch hierbei das potentielle Cross-Site Scripting. Dabei können Nutzer über in der Programmierung ungeprüfte Variablen Inhalte in diese Programmierung einschleußen und so ungewollte Inhalte oder Ansichten der Webseite erzeugen, diese auch für eigene Zwecke (z.B. Spam-Versand) missbrauchen. Aus diesem Grund sollte jede Variable vor der Verwendung programmtechnisch geprüft und/oder angepasst werden. Wie oben bereits genannt ist dies bei Formularvariablen z.B. mittels der codec-Option xmlmask ratsam, bei Variablen die in SQL-Statements verwendet werden über codec:mysql etc.
Jede Funktion, die in VIO.Matrix für eine Webseite hinterlegt wird, hat einen eigenen Aufbau. Manche Funktionen benötigen mehrere Layouts um alles Nötige abzubilden. Hier gilt es lediglich nicht den Überblick zu verlieren - Konzentration auf das Wesentliche!
Innerhalb dieser Funktionen werden häufig #IF-Bedingungen verwendet. Bei diesen muss man anders als bei anderen Programmiersprachen darauf achten, dass sowohl Beginn wie auch Ende der Bedingung komplett richtig geschrieben sind.
Negatives Beispiel:
Bei diesem Beispiel fehlt der #ELSE-Bereich, was zu einem Problem bei der Ausgabe führen wird.
Positives Beispiel:
Wie auch bei anderen Programmiersprachen sollte man bei den Vergleichen auch auf Typengleichheit achten. Strings sollten mit Anführungszeichen umgeben werden - auf beiden Seiten der Variablen bzw. Strings. Ein fehlendes Anführungszeichen innerhalb der #IF-Bedingung würde einen Fehler verursachen.
Weiterhin ist es wie auch bei normalen HTML-Templates oder anderen Programmiersprachen ratsam den verwendeten VIO.Matrix- wie auch HTML- oder XML-Code einzurücken. Dadurch erhöht sich die Übersichtlichkeit enorm und man sieht als Programmierer schnell, ob etwas am Code nicht stimmt.
Ruft ein Besucher einen Ordner oder ein Element auf welches nicht mehr existiert, sieht er im schlimmsten Fall eine von VIO.Matrix generierte Fehlerseite. Da diese recht unansehnlich ist und den Besucher auch nicht zum Ziel führt ist es sinnvoll die Systemparameter error400, error401, error403 und error404 anzulegen. Diese können dann auf eine allgemeine oder projektspezifische Fehlerseite verweisen - und der Besucher findet trotz nicht mehr vorhandenen Ordnern oder Elementen den Weg zur eigentlichen Webseite.
Falls vom Projekt eine MySQL-Datenbank verwendet und auf diese über VIO.Matrix zugegriffen wird, sollte man sich hier bei Fehlern in SQL-Statements benachrichtigen lassen. Nur so kann man auch bestehende Probleme erkennen und beseitigen. Im einfachsten Fall wird dabei eine E-Mail an den Programmierer erzeugt. Für diese MySQL-Aufrufe verfügt VIOSYS bereits über ein vorgefertigtes VIO.Matrix-Modul, welches diese Aufgaben automatisch übernimmt. Zudem kann man sich so auch alle auf einer Seite verwendeten SQL-Befehle unterhalb der Seite ausgeben lassen, wodurch man als Programmierer wiederum den Überblick behält und auch die Wirkung dynamisch zusammengesetzter SQL-Statements nachvollziehen kann.
Eine weitere Problemklasse sind Zeichenkodierungen. Die Webseite muss immer so konzipiert sein, dass sie einen einheitlichen Zeichensatz zur Darstellung jeglicher Texte verwendet. VIO.Matrix unterstützt hier besonders wegen dem neuen Editor editor.dll den zukunftsträchtigen UTF-8-Codec von Haus aus. Für den Webprogrammierer gilt es nun diesen Zeichensatz in seiner Programmierung auch durchgehend zu verwenden. Die von VIO.Matrix bereitgestellten Codecs wie utf8 oder unutf8, das Pipelining zur Beeinflussung der Header der Seite sowie die einheitlich utf8-kodierte Ausgabe von Texten aus dem Editor vereinfachen die Arbeit enorm. Lesen Sie hierzu auch den Fachbeitrag der dieses Thema genauer beleuchtet und die Verwendung in VIO.Matrix erläutert.
Bei der Verwendung von #INSERT_SE_ZEILE innerhalb einer #SET-Anweisung passiert es, dass VIO.Matrix die Inhalte nicht wie gewünscht in der Variable speichert. Hier hilft es den genauen Unterlayout-Namen hinter #INSERT_SE_ZEILE zu ergänzen. Das sähe z.B. so aus:
In Verbindung mit codec:text kann man nicht die Länge der Ausgabe des codecs über die Sternchenvariable length ermitteln. Ein Trick um dies bei #IF-Bedingungen doch zu ermöglichen sieht so aus:
Der VIO.Matrix CIS verzeiht in vielen Zusammenhängen kleinere Eingabefehler von VIO.Matrix-Befehlen. Allerdings gibt es auch hier Grenzen. Durch ein fehlendes Ausrufe- oder Anführungszeichen in VIO.Matrix-Befehlen kann der Quellcode einer über VIO.Matrix erzeugten Seite fehlerhaft werden. Dies merkt man als Webentwickler jedoch meist sofort, da Browsererweiterungen wie Firebug, IE WebDeveloper oder HTML Validator solche Probleme im HTML- und CSS-Code sofort melden. Konzentriert man sich generell auf validen HTML- und CSS-Code bei einer Webseite kann man solche Probleme sofort sehen und beheben. Mehr dazu verrät der Fachbeitrag "Hilfe Tools zur Webentwicklung".
Als VIO.Matrix-Entwickler sollte man wie auch bei anderer Software immer den aktuellsten Stand der VIO.Matrix-Entwicklung verwenden. Die 2 Windows-Komponenten können unter update.viomatrix.de nach Angabe der Lizenznummer jederzeit angefordert werden.