Plugin-Review: Pods / Pods Framework

Das Plugin Pods ist mit Sicherheit nicht das bekannteste WordPress-Plugins.

Kein Wunder, schließlich sind auch nicht Anwender, sondern eher Entwickler die Zielgruppe. Mit Pods wird aus der Blog-Plattform WordPress ein echtes CMS zur Darstellung beliebiger Inhalte.

WordPress bringt natürlich Basis-Funktionen eines CMS-Systems mit sich. Wer über Blog-Beiträge und statische Seiten hinaus Inhalte darstellen will, kommt mit WordPress aber oft an seine Grenzen.

Viele Webseiten nutzen bereits WordPress als Blog-Plattform, wenn die Entscheidung zu einer Erweiterung getroffen wird. Wenn nur statische HTML-Seiten durch ein CMS ersetzt werden sollen, reichen die Standardfunktionen von WordPress problemlos aus. Werden individuelle Scripte verwendet, die z.B. Bewertungen oder Daten verwalten, stößt man mit WordPress schnell auf unlösbare Probleme.

Was kann Pods?

Mit Pods lassen sich eigene Datentypen kreieren und miteinander verknüpfen. Über Templates und Helper lässt sich die Ausgabe steuern, über die Url kann Inhalten automatisch ein Template zugewiesen werden. Das Framework ermöglicht es, beliebige Inhalte zu erstellen, zu verwalten und auszugeben.

Seit Anfang Oktober ist das Plugin in Version 2 erhältlich, zeitgleich zu WordPress 3.5 erschien die Version 2.1. Bemerkenswert ist, dass die Entwicklung von Pods mittlerweile auch von Auttomatic unterstützt wird

Im Versionswechsel liegt die aktuell größte Schwäche von Pods. Zur Zeit sind weder Dokumentation noch Framework-Erweiterungen auf dem aktuellen Stand. Gerade der Neueinstieg gestaltet sich durch die Änderungen etwas schwieriger.

Wann ist Pods zu empfehlen?

Pods ist zweifellos mächtig. Empfehlenswert ist das Framework vor allem aber dann, wenn bei einem neuen Projekt ein WordPress-Blog Teil der Seite sein soll oder der spätere Anwender bereits gute Erfahrungen mit WordPress gemacht hat.

Wer keine Blog-Komponente benötigt oder keine Komponenten oder Plugins aus WordPress verwenden möchte, dürfte mit einem Standalone-Framework wie z.B. Symfony 2 besser aufgehoben sein, da ansonsten ein unnötig großer Overhead mitgeschleppt werden muss und die große Verbreitung von WordPress auch Risiken und eine Notwendigkeit ständiger Updates mit sich bringt.

Fazit

Pods Framework ist kein Plugin für unerfahrene WordPress-Nutzer. Für Entwickler, die auf Basis von WordPress eine stark überarbeitete Seite erstellen wollen, ist Pods aber durchaus einen Blick wert.

Datenbanken, Klartext-Passwörter und Verschlüsselung

Sicherheitslecks und Hackerangriffe auf bekannte Seiten gab es in den letzten Monaten zur Genüge. Erstaunlicherweise gibt auch 2011 noch große Unternehmen, die Passwörter im Klartext in ihren Datenbanken speichern. So brachte ein Hack bei Sony Pictures die Passwörter von über einer Million Nutzer im Klartext zum Vorschein. Auch die REWE-Gruppe beauftragte einen Dienstleister, der sämtliche Kundenpasswörter unverschlüsselt speicherte.

Unverständlich ist dabei, wie Dienstleister mit solch offenkundiger Inkompetenz den Auftrag erhalten konnten. Ebenso unverständlich ist, wie der Fehler dem Auftraggeber bzw. der IT-Sicherheit entgehen konnte. Bereits bei der Vergabe des Auftrags muss die Sicherheit der Anwendung einen wichtigen Stellenwert einnehmen.

Wer heutzutage noch Passwörter im Klartext speichert, ist dem Stand der Technik bzw. des Wissens um Jahre hinterher. Einen solchen Dienstleister auf die eigenen Webseite und die eigenen Kunden “loszulassen” ist mehr als fahrlässig. Wenn in Ihrer Datenbank Passwörter unverschlüsselt gespeichert sind, besteht dringender Handlungsbedarf.

Manchmal stößt man bei der Prüfung bereits vorhandener Webanwendungen auch auf Kurioses. So habe ich bereits ein Script gesehen, bei dem der Entwickler offenbar nachträglich eine Verschlüsselung der Passwörter hinzufügte. Anstatt aber nun die bereits vorhandenen Passwörter ebenfalls zu hashen wurden nur neu erstellte Passwörter gesichert. Die Nutzer, die ihr Passwort nicht änderten, waren weiterhin gefährdet und es entstand eine wild durchmischte Datenbank.

Oftmals ist aber auch falsch verstandener Stolz ein Problem. Viele Entwickler programmieren eigene Passwort-Funktionen. Sei es, um “Kompetenz” zu signalisieren, um den Projektaufwand und damit ihre Bezahlung zu erhöhen oder auch wenn sie ein eigenes CMS verwenden bzw. vermarkten wollen.

Fehlende kryptographische Grundlagen oder schlampige Umsetzung einer eigenen Passwortverschlüsselung sorgt in den meisten Fällen aber dafür, dass die Verschlüsselung schlechter ausfällt, als bei etablierten Systemen wie z.B. phpass.

Die Passworterstellung und -verschlüsselung sollte etablierten Systemen wie dem erwähnten phpass oder dem ggf. verwendeten Framework überlassen werden. Letztlich wird sowohl dem Auftraggeber, als auch dem Entwickler ein Gefallen getan. Der Auftraggeber erhält ein sichereres Produkt, der Entwickler hat mehr Zeit für Features – oder er spart Zeit und kann seine Dienstleistung günstiger anbieten.

Die Zeiten, in denen sich ein Programmierer damit “auszeichnen” konnte, wenn er möglichst viel selbst programmiert, sind eindeutig vorbei.