CMSBlog

Die Nachrichtenverlage legen ihre Hoffnungen derzeit auf Bezahlcontent. Mehr Einnahmen zu generieren ist auch dringend notwendig, um die Qualität aufrecht zu erhalten und die Erosion der Entlohnungen zu stoppen.

Ein Problem sehe ich allerdings darin, pro Artikel zu bezahlen, nicht nur wegen Hürden in der Wertfestlegung und Transaktionskosten (Carta hat dazu einen guten Artikel geschrieben). Ich glaube, dass die Kosten pro Artikel bei der Verwendung von Micropaymnet zu hoch bleiben.

Vorstellen kann ich mir eine Sammelrechnung. Dabei wird pro Klick gezählt und erst abgerechnet, wenn ein bestimmter Wert, z.B. 5 €, erreicht ist. Wird der Wert in einem Zeitraum längeren Zeitraum – ein paar Monate oder ein Jahr – nicht erreicht, wird nicht abgerechnet und der Kunde erhält somit einen kostenlosen Probezugang. Die Kosten pro Klick sollten im normalen Gebrauch an einem Tag die Kosten einer Tageszeitung nicht übersteigen.

Nicht besonders sinnvoll finde ich auch den Ansatz, Bezahlcontent teilweise als Vorschau kostenlos bereit zu stellen. Als Nutzer finde ich es frustrierend, ständig nur Schnipsel der eigentlichen Information zu erhalten. Die Anbieter sollten einfach darauf vertrauen, dass sich Qualität herumspricht und ein exklusiver Zugang seinen Mehrwert hat.

Gerade dieser Exklusivzugang würde es auch wieder andere Angebote aufwerten. Ein Anzeigenmarkt oder Stellenangebote bekommen dadurch eine ganz andere Wertigkeit. Auch exklusive Werbung kann dann punkten, wenn sie informativ ist und eine echte Information darstellt.

Es gibt viele weitere Faktoren für den Erfolg eines solchen Konzepts. Dazu gehört ein großer Verbund, der mehrere Angebote vereint, eine gemeinsame Suche anbietet und die gleichen Abrechnungssysteme verwendet.

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.

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.

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 …

Nun soll es wieder mal ein großes Leck geben: laut Wirtschaftswoche sind über eine Millionen Bankdaten in Händen von Kriminellen. Mit diesen Daten können. Wenn das wahr ist, sind die Daten inzwischen vielfach kopiert und können die nächsten zwanzig bis dreißig Jahre benutzt werden. Da kann man Jahrzehnte lang Rentner abzocken. Was war das noch mühsam bis in die 90er, als noch schauspielerische Leistungen gefordert waren, die wir bei Aktenzeichen XY lernen konnten! Ne, die Daten gibt es nicht zurück, die sind kopiert, verteilt, verkauft.

Und wer jetzt noch glaubt, dass sensible Daten bei Callcentermitarbeitern sicher sind, die einen halbierten Lohn bekommen – absehen von der nicht bezahlten Moralverdrängungspauschale – , sollte eines besseren belehrt sein. Mit dem Geld sinkt die Moral. Und wer wird verknackt? Die Verantwortlichen für die Daten? Glaub ich nicht.

Ich finde, nun sind die Banken am Zug. Sie müssen die Konten vor einem unberechtigten Zugriff schützen.

Nun muss ich mal etwas Werbung in eigener Sache machen: wir haben einen Singkreis hier in Köln, mit dem wir – zur Zeit jedem Mittwoch – Lieder singen und uns unterhalten. Ein richtiger Chor ist das nicht und soll es auch nicht werden. Für uns zählt das Treffen, das mit gemeinsamen Musizieren gewürzt wird.

Da wir jetzt nur noch drei Leute sind (eigentlich fünf, aber man weiß ja wie das so ist mit der Zeit und dem Ort) wollen wir uns mal wieder darum kümmern, etwas zu wachsen. Wer also etwa zwischen 30 und 50 ist, singen will oder ein wohnungsfreundliches Instrument spielt, darf sich gerne bei uns melden.

Wir singen Lieder wie Mr. Tamborine Man, Bey bey love, Blowing in the Wind, Griechischer Wein, Heute hier, morgen dort, Whata wonderfulll Worls, Hiroshima, Space Oditty und viele mehr – wo wir Lust zu haben und die nicht so schwer sind.

Also, wer Lust und ein wenig Zeit hat, schreibt mir einfach eine E-Mail an info@harald-kampen.de.

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.

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

• Wikipedia zu Cross-Site Scripting
• Offizielle PHP-Infos zu register_globals
• www.cms-sicherheit.de bietet einen guten Überblick über Sicherheitsrisiken und Lösungen.
• Sicherheiterweiterung Suhosin für PHP
• mod_security für Apache

Unter en.kauleev.org ist die Website vom Kaule e.V. auch auch englisch verfügbar. Zur Zeit arbeitet der Verein an einem Landwirtschaftsprojekt in Nepal.

Seit einiger Zeit mache ich beim Kaule e.V. mit, der in Agrarprojekte in Nepal und anderen armen Regionen dieser Welt fördert. Ich fand die Idee gut und hab dann auch gleich zugesagt, die Website umzusetzen. Ich würde mich freuen, wenn ihr den Auftritt fleißig besucht und euch mal Gedanken über eine Spende macht.

Das Projekt wird schon länger vorbereitet und die Leute sind verlässlich und fachkundig; es ist kein Heileweltverein und auch kein Entwicklungshilfekonzern. So bekomme ich aus erster Hand mit, was geplant und umgesetzt wird und wohin die Gelder fließen. Das spiegelt sich auch in den Inhalten der Homepage wider.