CONTENIDO Forum

Hallo Contenido-Crew,

Ich finde es prinzipiell sehr gut, das ihr jetzt schon ein eingebundenes PEAR-Grundpaket mitliefert.

Leider ist es nicht so gut, das dabei nicht die Original-PEAR Verzeichnisstruktur benutzt wird!

Beispiele:
XML_Node liegt normalerweise nicht in PEAR/XML sondern in PEAR/XML/Tree.
Cache_Lite gehört in den Ordner Cache/ und nicht CACHE/

Ausserdem sollte in der Konfigurationsdatei ein Schalter eingebaut werden, mit dem man das interne PEAR abschalten (oder einschalten) kann, da es sonst Probleme mit Servern geben kann, auf dem das Original-PEAR bereits installiert ist!


Nur als Anregung für eine ordentlich Integrität...

Nun, um "Anregungen" zu geben, braucht man nicht ständig in Fettschrift zu schreiben bzw. zu blöken

Was den Schalter zum abschalten des mitgelieferten PEAR angeht, muß ich Dir zustimmen.

Was den Rest angeht, ohne mich näher mit PEAR auseinandergesetzt zu haben: Wenn ein Tool - wie z.B. PEAR - auf eine starre Verzeichnismimik angewiesen ist, darf es diese nicht konfigurierbar machen, ansonsten kann man das Tool in eine Struktur nach gutdünken implementieren.

IMHO ist es aus Sicherheitsgründen prinzipiell nicht verkehrt ein Tool nicht in den vorgefertigten Strukturen zu nutzen sondern die Strukturen soweit möglich "zu verbiegen", so das es einem Angreifer ggf. zumindest etwas schwerer Gemacht wird.

Wem die mit Contenido ausgelieferten Strukturen nicht passen, kann sie ja wieder auf das Original zurückdrehen.

Gruß

Arno

Wenn ein Tool - wie z.B. PEAR - auf eine starre Verzeichnismimik angewiesen ist, darf es diese nicht konfigurierbar machen, ansonsten kann man das Tool in eine Struktur nach gutdünken implementieren.

PEAR ist aber ja nun mal geschaffen worden, um eine einheitliche und allseitig kompatible Entwicklung zu ermöglichen... und ausserdem kein "Tool", sondern eine Objektbibliothek, deren Module aufeinander aufsetzen!

Was zum Beispiel, wenn ich mein Contenido um Module erweitern möchte, die andere PEAR-Klassen benutzen, als die (paar) mitgelieferten

Wenn ich z.B. das SOAP-Paket nutzen möchten, benötigt dies die ordentliche Dateistruktur des PEAR-Frameworks, d.h. Node.php in XML/Tree/, usw.

Zur Sicherheit:
PEAR sollte ohnehin im include_path des Servers liegen, da sonst gar nichts geht! Wenn ich also (als Angreifer) auf eine PEAR-Klasse zugreifen möchte, brauche ich die Klasse nur einzubinden. wenn ich das machen kann, brauche ich Zugriffsberechtigungen für ausführbare Dateien auf dem Server. Wenn ich diese Rechte habe, ist zum Hacken der Seite PEAR nun wirklich nicht mehr relevant - ich kann ja eh machen, was ich will...
Im Übrigen sollte das PEAR-Verzeichnis ohnehin nicht öffentlich zugänglich sein, d.h. ausserhalb des DOCUMENT_ROOT liegen!

Wem die mit Contenido ausgelieferten Strukturen nicht passen, kann sie ja wieder auf das Original zurückdrehen.

Und dann? Contenido umschreiben und sämtlich Pfade umschreiben? Vielen Dank für die Arbeitserleichterung...!

Fazit: Sicherheitsprobleme auf Webserver entstehen bestimmt nicht durch eine einheitliche Verzeichnisstruktur von PEAR! Wenn man eine Software auf einem solchen Framework aufsetzen will, sollte man zur Vereinheitlichung der Schnittstelle auch das Framework nutzen, und sich nicht irgenwas zusammenbasteln und das unter dem Original-Namen verbreiten.

Caddata hat geschrieben:... und ausserdem kein "Tool", sondern eine Objektbibliothek, deren Module aufeinander aufsetzen!

Auch eine "Objektbibliothek" sehe ich als Programmierer immer noch als Tool bzw. Toolsammlung an....

Diese Bibliotheksammlungen mögen gut und effektiv sein. Leider haben sie in meinen Augen allerdings in der Regel einen "kleinen" Nachteil, insbesondere wenn die eine Klasse auf der anderen aufbaut und somit ihr vorhandensein etc. bedingt:

Sie verschlingen zu viel Speicher und sind somit für die Verwendung auf shared Webspace in der Regel nur bedingt zu gebrauchen, da hier die restriktionen der Provider in der Regel zu ausufernd sind

Gruß

Arno

Hab bis vor drei Monaten ebenfalls das 1&1 Premium-Paket benutzt (shared Hosting) und keine Klagen vom Provider bekommen...

Betrieben wurde ein selbstgeschriebenes CMS, welches alles in allem um die 15 PEAR-Klassen benutzt (allerdings nicht gleichzeitig!).

Und für einheitliche Softwarekomponenten-Programmierung sollte Shared Hosting nicht das Maß der Dinge sein - schliesslich sind CMS (wie Contenido) eher im Profibereich zu Hause und sollten auch dafür konzipiert sein!

Nichts für ungut und ich möchte mich auch nicht als totaler PEAR-Verfechter hinstellen, aber ich meine, wenn schon PEAR, dann richtig!

Caddata hat geschrieben: Beispiele:
XML_Node liegt normalerweise nicht in PEAR/XML sondern in PEAR/XML/Tree.
Cache_Lite gehört in den Ordner Cache/ und nicht CACHE/

XML_Node lag AFAIK damals wirklich unter XML und nicht unter Tree -> das ist allerdings schon eine Weile her.

Ausserdem sollte in der Konfigurationsdatei ein Schalter eingebaut werden, mit dem man das interne PEAR abschalten (oder einschalten) kann, da es sonst Probleme mit Servern geben kann, auf dem das Original-PEAR bereits installiert ist!

Gibt es bereits. Siehe Config. Allerdings können wir dann nicht mehr garantieren, daß alles so läuft, wie es soll, da einige PEAR-Maintainer die Interfaces ihrer Klassen modifizieren.

Gibt es bereits. Siehe Config.

OOPS Gefunden -SORRY für den Einwand...

Allerdings können wir dann nicht mehr garantieren, daß alles so läuft, wie es soll, da einige PEAR-Maintainer die Interfaces ihrer Klassen modifizieren.

Ok, da müsste man über ne Art Versionskontrolle rangehen...

gehe ich denn Recht in der Annahme, das Contenido künftig verstärkt PEAR verwendet, oder ist das nur so ne Art Ergänzung?

Caddata hat geschrieben: Ok, da müsste man über ne Art Versionskontrolle rangehen...

gehe ich denn Recht in der Annahme, das Contenido künftig verstärkt PEAR verwendet, oder ist das nur so ne Art Ergänzung?

Das kommt drauf an - leider bietet PEAR nicht die Klassen, die wir benötigen, daher wird relativ viel dazuentwickelt. Ob die Klassen später ins PEAR kommen ist fraglich, da wir intern nicht PEAR-konform entwickeln (können).