Ich hab ein schickes Tool gefunden für die Qualitätsüberprüfung. Sauber gemacht und auch in der kostenlosen Version gut brauchbar: der qualidator. Diesen Blog hab ich da noch nicht mit getestet, da müsste ich erstmal vorher ein wenig tun 
Aber die Vereinsseite Kaule e.V. schneiden mit über 86% schon recht gut ab.
Archiv für Kategorie
Qualitätssicherung qualidator
Brainstorming Ressourcenbasierendes Framework?
Ich schleppe schon einige Zeit ein Konzept bzw. eher eine Idee mit mir rum, das ich leider selbst aus Zeitgründen nicht umsetzen kann: das ressourcenbasierendes Framework (RF). Möglicherweise ist das Prinzip nicht ganz neu, aber mir ist bisher noch kein derartiges Framework oder CMS untergekommen.
Auf die Idee bin ich gekommen, weil CMS- bzw. Blogsoftware häufig zu starr ist, um schnell ein neues Feature zu implementieren. Der Weg von typenbasierenden Seiten, also mit der Unterteilung ‘Seite’, ‘Blog’, ‘Termin’ usw. in eine flexibel kombinierbare Ausgabe zieht häufig einen kompletten Umbau nach sich – oder ist abhängig von spezialisierten Schnittstellen.
Auch wenn ich mich gerne mit Konzepten beschäftige und z.B. bereits das Zend Framework oder Symfony kennengelernt habe, ist mir der Weg zu einer fertigen Anwendung noch zu lang, oder wenn ich kein eingefleischter Anwender bin, auch zu kompliziert.
Ressourcen als Basis
Während die meisten CMSs oft diverse vollkommen voneinander unterschiedliche Contentelemente kenne, darunter Plugins, Seiten als News, Termine, statische Elemente usw., kennt das RCMS nur einen Grundtypen: die Ressource.
Eine Ressource kann sich die Inhalte aus diversen Quellen holen, z.B. Datenbanken, Textdateien, Templates oder Webservices. Für jede Resource werden normalerweise zwei standardisierte Command-Klassen bereit gestellt, jeweils für die Einrichtung im CMS-Backend und für die Ausgabe im CMS-Frontend.
Definition des Ressourcentyps
Je nach Aufgabe gibt es verschiedene Grundtypen von Ressourcen. Typisch sind programmorientierte Ressourcen wie Datenbankverbindungen, ACL, Request und Response und ausgabeorientierte Ressourcen, wie z.B. für HTML Header und Visible Content, die nach den Aufgaben weiter unterteilt werden.
Resourcegruppen
Die Ressourcen werden für den Einsatz über eine Konfiguration zusammengestellt. Eine grundlegende Konfiguration erstellt den gewünschten Aufruf. Wird ein Seitentemplate verwendet, erhält dieses Template ebenfalls eine Konfiguration, um die für die Seite verfügbaren Ressourcen zu definieren. Mit weitere Konfigurationen werden Ausgabetypen wie z.B. ein Blog, eine Seite, ein Download usw. mit Standardelementen und Standardtemplates definiert. Ergänzt wird die Konfiguration über dynamische Einstellungen und Einstellungen aus den einzelnen Ressourcen, die sich gegenseitig beeinflussen können.
Jede Ressourcegruppe stellt selbst eine Ressource dar. So können Ressourcegruppe ineinander verschachtelt werden.
Abarbeitung der Ressourcen
Die Abarbeitung erfolgt mit einem Controller in mehreren Schichten. Immer verfügbar sind die Schichten prepare, execute und view. Mit prepare werden Parameter zusammengestellt. Dabei kann auch die Ressourcegruppe beeinflusst werden, um auf zusätzliche Ressourcen zuzugreifen, Ressourcen oder ganze Ressourcengruppen zu entfernen oder zu ersetzen.
Die zweite Schicht, execute, führt optional logische Operationen aus.
Mit view wird die Ausgabe generiert, soweit dies erforderlich ist.
Vor- und Nachteile
Der Vorteil ist eine hohe Erweiterbarkeit und Flexibilität. Ressourcen können relativ einfach ersetzt, ergänzt oder neu kombiniert werden. Durch die einheitliche Schnittstelle für alle Ressourcen müssen sich Anwendungsdesigner weniger um die technischen Hintergründe kümmern, sie müssen nur noch wissen, welche Daten sie aus welcher Ressource zurückbekommen.
Ein Nachteil ist möglicherweise die hohe Anzahl der Dateizugriffe. Spätestens bei komplexeren Aufgaben muss für jede Ressource eine Klasse erstellt werden. Es kann auch schnell zu einem Konfigurationsoverhead führen.
Semantik und Struktur: Sind Definitionslisten sinnvoll für Forumlare?
Zuerst einmal frage ich mich immer wieder, was wirklich semantisch richtige Inhalte für eine Definitionsliste sind. Das W3C gibt als Beispiel eine Person mit der dazu gehörigen Aussage an. Ist der Name noch eine Definition? Oder im FAQ, sind die Fragen eine Definition? Als eindeutige Anwendung fallen mir dabei Begriffserklärungen ein, oder Kontaktdaten.
Ok, hier soll es aber um Formulare gehen. Da habe ich im Normalfall eine Beschreibung – also ein Label – für das Eingabefeld und das Eingabefeld selbst. Ein Label ist eine Definition eines Elements, insofern würde ich schon sagen, dass eine Definitionsliste auf Formularelemente angewandt werden kann. Aber umgekehrt, als wie es bisher genutzt wird! Denn dann ist das Eingabeelement der Definition Term (DT) und das Label Definition Data (DD).
Nun würde ich selbst nie auf die Idee kommen, Formulare in Definitionslisten zu packen. Es ist einfach zu unpraktisch bei der Formatierung. Es scheint aber modern zu sein …
PHP Arrays sind schneller als Objekte
Ich hab gestern mal Arrays mit stdClass-Objekten in der Datenabfrage verglichen. Bei kurzen Schlüsseln sind Array bis zum Faktor 1:1,3 schneller, bei längeren Schlüsseln 1:1,2. Noch deutlicher fällt der Unterschied aus, wenn im Array Integer als Schlüssel verwendet werden.
Sicherheit Javascript ausschließen mit PHP
Es kommt immer wieder vor, dass in Websites unerlaubtes Javascript eingeschmuggelt wird. Um einen Text mit Javascript auszuschließen, müssen eine Reihe von Möglichkeiten beachtet werden. Diese sogenannten XSS-Attacken (cross side scripting) können viel anrichten, zum Beispiel indem Paßwörter durch gefälschte Formulare abgefangen werden. Gelingt es, den Code in der Datenbank zu speichern, kann er als regelrechter Virus genutzt werden und weitere Änderungen vornehmen.
Mit den Zeichen >, <, " und ' kann HTML auf einer Website verändert werden. Werden diese Zeichen in Entities umgewandelt, also >, <, " und ', ist die Gefahr weitgehend behoben. Alternativ können diese Zeichen auch aus allen Benutzereingaben gelöscht werden.
Es reicht nicht, > und < umwandeln. In der Website kann es vorkommen, dass Inhalte von Benutzern auch innerhalb von HTML-Tags ausgegeben werden. Je nachdem, wie das HTML aufgebaut ist, können ohne Zeichenumwandlung HTML-Attribute wie onload oder onclick (Events) eingeschleust werden.
Beispiele, wie es nicht gemacht werden soll:
Ungefiltert kann hier in mehreren Versionen Code eingeschleust werden:
<?php
echo '<a href="search.php?search='
.$_GET['search']
.'">Suche</a>';
?>
Damit bieten sich dem Angreifer mehrere Möglichkeiten, Javascript einzuschleusen:
<a href="search.php?search="><script>alert ('Angriff!');</script>">Suche</a>
<a href="search.php?search=" onclick="alert ('Angriff!');">Suche</a>
Für Angriffe besonders anfällig sind <input>- und <textarea>-Elememte, da bei falscher Eingabe die Benutzereingaben gerne wieder ausgegeben werden.
Ein Lösungsansatz
Der Lösungsansatz gilt nicht für Bereiche, wo der Anwender HTML abspeichern darf. HTML muss anders überprüft werden!
Viele Wege führen nach Rom, darum will ich erstmal einen Lösungsansatz vorstellen. Auf öffentlichen Seiten filter ich mit einer Klasse alle REQUEST-Parameter, indem ich die Zeichen >, <, " und ' mit >, <, " und ' ersetze, und zwar in $_REQUEST, $_POST und $_GET. Alternativ kann ich auch die Zeichen mit Leerzeichen ersetzen.
Ich kann dann diese globalen Variablen wie bisher weiter benutzen, muss aber beachten, wo ich die Quelle benötige. Ob ich die veränderten Werte in die Datenbank speichere, hängt davon ab, wie sie weiter verarbeitet werden sollen. ‘Mustermann & Söhne’ ist nicht das gleiche wie ‘Mustermann & Söhne’ und beeinflußt Suchergebnisse. Falls die Daten später wieder auf der Website dargestellt werden sollen, müssen sie auch erneut umgewandelt werden. Passwörter sollten nie gefiltert gespeichert werden.
Um auf die ungefilterten REQUESTs zugreifen zu können, speichere ich mir eine Kopie ab.
Mit diesem Code mit Anwendungsbeispiel können ohne viel Aufwand spezielle Filter erstellt werden. Der Code steht unter MIT-Lizenz (Open Source).
Andere Risiken
Es gibt noch diverse Risiken, die über REQUESTs auftreten können. Grundsätzlich sollten alle REQUESTs auch inhaltlich überprüft werden.
Besonders anfällig sind dabei E-Mail-Parameter – insbesondere Betreff und E-Mailadresse -, Datei- und Verzeichnispfade, SQL-Queries und andere Speicherformate und Systemaufrufe.
Quellen
Neue Bildschirme: Pixel ist (k)ein relativer Wert
Keine Ahnung, wie sie es machen wollen. Nun gibt es ja schon Bildschirme mit einer hohen Auflösung, und unsere geliebten Webpixel sind als relativ gekennzeichnet. Ein Pixel, also in der Darstellung ein rechteckiges Feld, dem Farben zugewiesen werden, ist eine Computereinheit. Pixel sind immer relativ zu Ausgabe, auf dem Bildschirm zuerst einmal abhängig von der Auflösung des Geräts.
Wird in Webseiten oder anderen Webformaten jetzt ein Pixel ausgegeben, gehen alle von einer Auflösung von 96 Pixel pro Zoll aus. Damit ist die Einheit nicht mehr relativ. Würde von 72 Pixel pro Zoll ausgegangen, wäre die Einheit in diesem Fall identisch mit dem Maß Punkt, was vieles erleichtern würde.
HTML 5 Ein kleiner Einstieg in HTML 5
Der lange erwartete Nachfolger von HTML 4.01 und XHTML 1 ist noch kein fertiger Standard. Da er in nahezu allen akuellen Browsern noch nicht umgesetzt ist, wird bisher noch davon abgeraten, ihn einzusetzen. Mit der endgültigen Verabschiedung wird es sicher auch noch dauern: Die Entwickler von HTML 5 rechnen mit 10-15 Jahren, bis die großen Webbrowser die Vorgaben sauber umgesetzt haben.
Es lohnt sich aber sicher, sich ein paar Grundlagen anzueignen. In diesem Beitrag will ich der Einfachheit halber XHTML 5 einmal außen vor lassen. Auch auf die vielen neuen Elemente und Attribute gehe ich hier nicht ein. Dazu wird es in Zukunft sicher diverse Anleitungen in Infos geben.
Firefox Operator
Ein schönes Plugin für die Entwickung und Nutzung von Microformats is die Firefox-Erweiterung Operator. Neben diversen Möglichkeiten, mit Microformats umzugehen bietet Operator auch einen Debug-Modus und eine grafische Hervorhebung.
So, nun muss ich aber den Fehler finden …
Wunschliste 2008 Was Browser können sollten
Spontan und subjektiv schreibe ich mal meine Wünsche für Browser auf. Wenn mir was einfällt oder ich einen passenden Vorschlag bekomme, schreibe ich es dazu.
Webstandards
- Der Internet Explorer 6 muss verschwinden.
- Kompromisslose Einhaltung der Standards HTML 4.01, XHTML 1 und CSS 2.1.
- Vollständige Unterstützung von SVG.
- Einbettung von SVG in text/html.
Formulare
- Kombiniertes Eingabe- und Selectfeld.
- Vollständige Gestaltung mit CSS aller Elemente.
Javascript
- Verbesserte Richtexteditoren in vielen Bereichen, darunter Code abhängig von Mimetype oder Doctype, Javascript-Facades für die Eingabe von CSS-Klasse, Sprachauszeichnungen und Abkürzungstags.
- document.write() auch für XML.
CSS
Alles, was in anderen Programmen schon längst normal ist …
- Hintergrund mit Verlauf.
- Hintergrund mit mehreren Bilder.
- Umfangreiche Möglichkeiten, Rahmen zu gestalten, wie z.B. Eckenrundungen.
- Transparente Schatten.
- Klassen innerhalb von Deklarationen wiederverwenden, um z.B. Farben und Schriftarten zentral zu definieren.
- Mehrspaltigen Textsatz.
HTML
- Vectorbasiender Textumfluß mit dem MAP-Element.
- Automatische Anpassung der Höhe von Iframes an den Inhalt mit CSS- oder HTML-height.
Allgemein
- OS-seitige Silbentrennung, auch genutzt in Browsern.
- Klare Standards für Useragent-Header, unter anderem mit Versionsnummer, OS und Bildschirmauflösung.
Update: 20.1.2008, 3 Uhr
HTML 5 Sie streiten wieder
Heftige Kritik wurde die Tage an WHATWG und der Umsetzung von HTML 5 laut. Bemängelt wird vor allem die mangelnde demokratische Struktur und der Umgang mit Barrierefreiheit. Einfach für Alle hat dazu einige Links zusammengestellt.
Aus meiner Sicht ein Problem, das auch XHTML 2 betrifft. Statt in kleinen Schritten neue HTML-Versionen zu verfassen und, die auch kurzfristig in neuen Browserversionen verfügbar sind, wurde mit HTML 5 der große Wurf
versucht. Wenn nach jahrelanger Arbeit kein Feedback aus der Praxis kommt, ist klar, dass Frust aufkommt.
