Mein Hirn is grad sowas von vernagelt, ich brauch mal ne zweite (oder auch dritte) Meinung. Hier mal die allgemeine Beschreibung:

Ich hab ein Skript mit Datenbankverbindung, das Erweiterungs-Module (Plugins) laden kann.

Einerseits will ich die Module nicht einschränken und Zugriff auf die komplette Datenbank ermöglichen.

Andererseits hab ich mir überlegt, das ich doch gerne die Daten oder den Zugriff auf die DB-Tabellen irgendwie abstrahieren und absichern möchte. Zum einen damit die Erweiterungsmodule noch funktionieren, wenn sich die Datenbank ändert, zum anderen weil man nie weiss wie gut oder schlampig die Erweiterungen geschrieben werden (und ich will kein kostenloses Code-Review für jedes neue Modul machen).

Erste Idee:
Eine DB-Klasse die instanziert, an die Erweiterung übergeben wird und dazu dient die Datenbank abzufragen. Diese liefert die entsprechenden Daten-Objekte an die Erweiterung zurück (sozusagen Factory Light). Ungefähr so Scheidet aber aus, da diese Klasse bei jedem neuen Modul wieder um die passenden Objekte erweitert werden müsste.

Zweite Idee:
Jede Erweiterung muss eine Art Installations-Sub bereitstellen, die einmal aufgerufen wird um das Modul zu aktivieren bevor es verwendet werden kann. Dabei muss das Modul beim Skript "anmelden" mit welchen DB-Tabellen es arbeiten will. Versucht das Modul auf andere Tabellen zuzugreifen, wird abgebrochen und ne Fehlermeldung ausgespuckt. Ist zwar nur die halbe Miete, sollte aber das gröbste an Schindluder von der Benutzerseite verhindern.

Dazu brauchts aber auch eine DB-Klasse, die die Zugriffe kontrolliert. Kompletter SQL-Parser ist nicht akzeptabel (bzw. zu aufwändig) und Subroutinen ala sind bei einfachen SQL-Statements ja noch machbar, aber bei komplexeren WHERE-Klauseln mistig bis totaler Krampf.

Grosse Frage: Wie würdet Ihr das implementieren oder habt Ihr ne andere zündende Idee?

Wenn du Kontrolle über die Datenbank hast, könntest du ein weniger priviligerten DB-Benutzer anlegen, mit diesem Benutzer eine zweite Verbindung aufbauen und an Plugins nur die unprivligierte Verbindung weitergeben.

Die Datenbank hat ja schon eine Zugriffskontrolle, es wäre Unfug das noch mal von Hand im Application Space nachzubauen.

Ist in den meisten Fällen leider nicht machbar. Es geht mir auch eigentlich nicht darum Plugins in dieser Art zu beschränken und wartungstechnisch ist das nicht leicht zu pflegen. Jedesmal wenn sich die DB ändert, müssen die Rechte angepasst werden.

Es geht primär darum eine mögliche SQL-Injection über ein schlecht geschriebenes Plugin abzufangen, indem im Applikationsskript kontrolliert wird, welche Datenbanktabellen (oder besser -spalten) ein Erweiterungsmodul abzufragen versucht. Wenn es die sind, die der Plugin-Author angegeben hat ist alles gut, wenn nicht streikt das Skript.

Das mit der Datenbankabstraktion bzgl. DB-Änderungen hab ich mir schon abgeschminkt und je länger ich darüber nachdenke wird mir zähneknirschend klar, das ich wohl einen SQL-Parser einsetzen muss.

Grade drüber gestolpert...

SQL::Abstract scheint ein ganz vernünftiger Kompromiss zu sein. Die Erweiterungen müssten keine eigenen Statements mehr bauen, die Syntax ist simpel und flexibel genug für die meisten Fälle. Obendrein hat SQL::Abstract keine weiteren Abhängigkeiten und ist kein 0.x Release mehr.

Wie sind denn eure Erfahrungen mit SQL::Abstract?

SQL::Abstract ist für einfache bis mittelschwere Abfragen echt cool, aber sobal die SQL-Statements "hässlich" werden, ist das mit SQL::Abstract nicht unbedingt besser.