Arbeiten mit (Pseudo)Packages

**unset** · 15.07.2010, 21:51

PHP 5.3 kommt mit PHAR.

**Kropff** · 15.07.2010, 21:54

Als Allererstes solltest du dir Gedanken über mögliche Sicherheitsrisiken machen. Denn bei einem schlampig programmierten Modul bekommst du riesengroße Probleme. Noch schlimmer ist es, wenn jemand ein Hack-Modul einschleust.

Überleg dir also zuerst, welche Sicherheitsmechanismen du einbaust, bevor du dich an die Umsetzung wagst.

Peter

**ApoY2k** · 16.07.2010, 09:27

Okay, wo wir grade davon sprechen. Du hast mich natürlich wie so oft direkt dort getroffen wo ich am wenigsten geplant habe ;-) Momentan kann ich Plugins ohne Probleme laden, auch Abhängigkeiten berücksichtigt etc.

Die Frage nach der Sicherheit kam noch garnicht auf. Ist aber auch ein schweres Thema, momentan bin ich auf folgendem Stand;

Ich denke das gefährlichste "Hacking"-Plugin wäre ein solches, welches Schaden an der Datenbank verursacht oder Daten anderer Plugins ausliest oder ändern kann.

Daher darf jedes Plugin sich Tabellen erstellen (das wird beim Installieren über eine .xml erledigt) und dann auch nur diese Tabellen verwenden, sprich jeder Zugriff auf die Tabellen anderer Plugins oder des Systems selbst wird verhindert.

Die Frage nach den Funktionen der Plugins ist so eine Sache, im Grunde möchte ich es schaffen, dass wirklich jedes Plugin prinzipiell ALLES machen darf, solange es eben nur das Plugin selbst betrifft. Ich möchte eigentlich davon absehen, ein Framework an Funktionen zur Verfügung zu stellen, da ich damit immer die Kreativität der Entwickler einschränke.

Bleibt das Problem, was ein Plugin an sich schädliches ausrichten könnte, wenn die Sache mit der Datenbank so klappt wie ich es oben erklärt habe.

**ThemBones** · 16.07.2010, 10:02

Zitat von ApoY2k Beitrag anzeigen

Daher darf jedes Plugin sich Tabellen erstellen (das wird beim Installieren über eine .xml erledigt) und dann auch nur diese Tabellen verwenden, sprich jeder Zugriff auf die Tabellen anderer Plugins oder des Systems selbst wird verhindert.
...
Ich möchte eigentlich davon absehen, ein Framework an Funktionen zur Verfügung zu stellen

Ein "Etwas", das nicht zumindest lesend auf die Daten der Anwendung zugreifen darf und/oder irgendeine API anspricht, ist nach meinem Verständnis aber kein Plugin sondern eine eigenständige Anwendung

**onemorenerd** · 16.07.2010, 10:03

Man kann zwar relativ einfach sicherstellen, dass ein Plugin nur die eigenen Tabellen benutzt, ich halte das allerdings für keine gute Idee. Stell dir mal vor du speicherst User/Accounts in einer User-Tabelle. Ein Plugin soll nun das Benutzerprofil erweitern. Dann wird es sicherlich Joins mit der User-Tabelle machen müssen. Wenn du das verbietest, muss das Plugin sich die User über eine PHP-Funktion (der Basisapplikation oder eines anderen Plugins) holen. Ohne Join wird das schnell zum Performanceproblem.
Außerdem hat die Basisapplikation oder ein anderes Plugin z.B. eine Funktion zum Löschen eines Benutzers. Wie willst du sicherstellen, dass diese Funktion nicht von einem "unbefugten" Plugin aufgerufen wird?

**ApoY2k** · 16.07.2010, 10:10

Zitat von ThemBones Beitrag anzeigen

Ein "Etwas", das nicht zumindest lesend auf die Daten der Anwendung zugreifen darf und/oder irgendeine API anspricht, ist nach meinem Verständnis aber kein Plugin sondern eine eigenständige Anwendung

Hmja ich habs vielleicht falsch erklärt. Im Grunde soll jedes Plugin für sich eine eigenständige Applikation sein, aber im Gesamtkonzept eines Programms nur ein Teil sein. z.B. Eine Möglichkeit für SEO-Plugins - das kann selbstständig laufen, wird aber in dem Kontext nur als Plugin eingebaut oder aktiviert, wenn man es haben möchte.

Zitat von onemorenerd Beitrag anzeigen

Man kann zwar relativ einfach sicherstellen, dass ein Plugin nur die eigenen Tabellen benutzt, ich halte das allerdings für keine gute Idee. Stell dir mal vor du speicherst User/Accounts in einer User-Tabelle. Ein Plugin soll nun das Benutzerprofil erweitern. Dann wird es sicherlich Joins mit der User-Tabelle machen müssen. Wenn du das verbietest, muss das Plugin sich die User über eine PHP-Funktion (der Basisapplikation oder eines anderen Plugins) holen. Ohne Join wird das schnell zum Performanceproblem.
Außerdem hat die Basisapplikation oder ein anderes Plugin z.B. eine Funktion zum Löschen eines Benutzers. Wie willst du sicherstellen, dass diese Funktion nicht von einem "unbefugten" Plugin aufgerufen wird?

Tja das sind eben die Fragen, die ich hier diskutieren möchte. Ich will ja jetzt nicht morgen ein perfektes universelles Pluginframework anbieten, aber damit beschäftigen und vielleicht gute Lösungsansätze herausfinden, die ich dann für Projekte nutzen kann. Aber ich habe mir auch andere Pluginsysteme angeschaut (z.B. WCF) und da läuft es meistens auch nur über "Shared"-Klassen, in denen Plugins Schnittstellen anbieten könne, damit sie von anderen Plugins genutzt werden können, eben z.B. um auf grundlegende Userfunktionen zugreifen zu können.

**onemorenerd** · 16.07.2010, 10:20

Du hast zwei Möglichkeiten:
1. API - das Framework stellt nur eine Art Schnittstelle für Plugins bereit,
2. Sandbox - das Framework führt Plugins in einem abgeschotteten Kontext aus.

Die erste Variante verzichtet auf jegliche Schutzmechanismen zur Laufzeit. Dennoch kannst du gewünschtes Verhalten sicher stellen, indem du bspw. nur geprüfte Plugins zuläßt (Prüfung = Code Review).
Die zweite Variante ist mit PHP nur schwer machbar (runkit Extension), komplex und wahrscheinlich weniger flexibel/mächtig.

**ApoY2k** · 16.07.2010, 10:25

Im Grunde wollte ich ebenfalls in Richtung des ersten gehen. Einfach um daran was zu lernen - Produktiv wirds wohl eh nie eingesetzt.

Ich nehme an du meinst mit Prüfung der Plugins, dass ich einfach den Code durchgehe und nachschaue, was es macht und dann sage "okay, genehmigt"? Ich denke das wäre fürs erste die beste Idee, wie gesagt: ich will vorallem was dran lernen.

Ist eigentlich eine schöne Idee, es gibt ja auch genügend Möglichkeiten auf die Integrität der Plugins zu testen über Hashes oder Keys... Eine Frage bleibt aber noch für die Package-geschichte. Eignet sich dafür dieses PHP Archive? Ist auch jeden Fall interessant zu lesen, bloß verstehe ich noch nicht so ganz, wie man diese Archive dann erstellt?

Mal angenommen ich bastle ein neues Plugin und will dann die ganzen Daten dafür packen, muss das dann über ein PHP-Skript laufen? Ich meine... es gibt ja kein Programm, das "PHAR" packen kann oder ?!

**onemorenerd** · 16.07.2010, 11:18

Zitat von ApoY2k Beitrag anzeigen

Mal angenommen ich bastle ein neues Plugin und will dann die ganzen Daten dafür packen, muss das dann über ein PHP-Skript laufen?

Ja.

Zitat von ApoY2k Beitrag anzeigen

Ich meine... es gibt ja kein Programm, das "PHAR" packen kann oder ?!

Versuch mal "phar" auf der Kommandozeile … im Endeffekt auch nur ein PHP-Skript, deshalb oben das Ja.

**ApoY2k** · 16.07.2010, 11:51

Hm okay, dafür könnte man natürlich einen Dienst anbieten. Müsste doch theoretisch möglich sein, dass man sagt "Diesen Ordner packen" und dann per PHP alle Dateien dieses Ordners in ein PHAR packt. sozusagen als Entwickler-Skript.

**fireweasel** · 17.07.2010, 21:52

Zitat von ApoY2k Beitrag anzeigen

... Eignet sich dafür dieses PHP Archive? Ist auch jeden Fall interessant zu lesen, bloß verstehe ich noch nicht so ganz, wie man diese Archive dann erstellt?

Mal angenommen ich bastle ein neues Plugin und will dann die ganzen Daten dafür packen, muss das dann über ein PHP-Skript laufen? Ich meine... es gibt ja kein Programm, das "PHAR" packen kann oder ?!

Man kann PHAR-Dateien auch als gewöhnliche ZIP- oder TAR-Archive[1] erstellen, in denen sich eine spezielle Datei, ein so genanntes Manifest und noch ein wenig zusätzliches Brimborium befindet. Wenn du mich fragst: gequirlter Mist, aber das ist man von den PHP-Machern ja mittlerweile gewohnt.

Wieder ein Batzen aufgeblähter Klassen mehr, mit denen wir rumspielen dürfen.

--
[1] Um die zu erstellen gibts unzählige Kommandozeilentools und auch welche mit GUI und wenn ich mich nicht irre auch diverse PHP-Klassen, mit denen man die passenden Archive selbst bauen (und packen) kann.

Arbeiten mit (Pseudo)Packages