strukturiertes Framework Setup hinbekommen

[MB]

moin Community,

wie macht man ein Framework Setup bezogen auf:

• seine Zugriffsrechte im Datensystem .htaccess
• Programm Entrypoint: new App() oder new Bootstrap()
• Inizialisierungen: Pfad Konstanten, Datenbank Setup, Routering Defaults usw.

ich habs probiert und Erfolge erzieht aber eine wirkliche struktur im Setup gab es bei mir da nicht 😕. Ich bräuchte Struktur im Framework und vorgehensweise wie das strukturieren kann.

vlg MB

[dedlfix]

Tach!

wie macht man ein Framework Setup bezogen auf:

• seine Zugriffsrechte im Datensystem .htaccess

Framework-Dateien und andere Helfer müssen nicht im DocumentRoot liegen. Da müssen nur Dateien hin, die ausgeliefert werden sollen. Da es aber nicht immer gegeben ist, dass man abseits des DocumentRoots Platz hat, sollte man es vorsehen, dass die Dateien auch innerhalb zu liegen kommen können. Solange nur Klassen und Funktionen aber kein direkt ausführbarer Code in den Dateien enthalten ist, passiert nichts weiter, wenn sie direkt über einen Request aufgerufen werden. Andererseits schadet es auch nicht, wenn selbst diese Dateien per .htaccess verboten werden. Unbedingt sollte man Verzeichnisse schützen (Ausfrufen von PHP-Dateien verhindern), in denen temporäre Dateien zu liegen kommen, wenn man solche Verzeichnisse nicht abseits anlegen kann. Dateien hochladen und sie dann im Temp-Verzeichnis aufzurufen ist eine beliebte Vorgehensweise zum fremden Projekten Müll unterzuschieben.

Was die Zugriffsrechte im Dateisystem anbelangt, kannst du als Außenstehender nicht viel machen und musst dem Administrator vertrauen, dass der die Projekte ausreichend voneinander abschirmt. Aber Hinweise kannst du in der Dokumentation geben, wenn du in irgendwelchen Verzeichnissen Schreibrechte brauchst.

• Programm Entrypoint: new App() oder new Bootstrap()

Wie du magst. Es ist nur ein Name. Wenn mehr dahinterstecken sollte, müsstest du die Funktionalität erläutern, damit man da was einschätzen kann.

• Inizialisierungen: Pfad Konstanten, Datenbank Setup, Routering Defaults usw.

Da ist ein Kompromiss zwischen Sicherheit und Komfort gefragt, in dem Sinne, dass man dem Verwender keine zu großen Hürden beim Konfigurieren in den Weg legt, die Sicherheit aber trotzdem gewährleistet ist. Ini-Dateien innerhalb des DocumentRoot sind beispielsweise aufrufbar, wenn man nicht irgendeinen wirksamen Zugriffsschutz installiert. Der Aufruf einer PHP-Datei, die einen Haufen Konstanten definiert, aber diese Werte nicht ausgibt, ist hingegen ungefährlich, solange der Webserver PHP-Dateien durch PHP ausführen lässt statt sie direkt auszuliefern.

Ansonsten kommt es gut, wenn diese Dateien einfach zu finden sind, das heißt entsprechend benannt sind.

dedlfix.

[MB]

moin dedlfix,

ersteinmal Danke für die AW. ich üb fleißig weiter

vlg MB

[pl]

Was die Zugriffsrechte im Dateisystem anbelangt, kannst du als Außenstehender nicht viel machen und musst dem Administrator vertrauen

Es ist ja davon auszugehen, daß ein setup mit root Berechtigung ausgeführt wird.

wenn du in irgendwelchen Verzeichnissen Schreibrechte brauchst.

...wird auch das vom setup erledigt. MfG

[dedlfix]

Tach!

Was die Zugriffsrechte im Dateisystem anbelangt, kannst du als Außenstehender nicht viel machen und musst dem Administrator vertrauen

Es ist ja davon auszugehen, daß ein setup mit root Berechtigung ausgeführt wird.

Nein. Nicht jeder hat einen eigenen Server für sich. Man sollte auch davon ausgehen, dass nur eingeschränkte Nutzerrechte zur Verfügung stehen.

Berechtigungen sind eine Frage, die man ohne die Kenntnis des Zielsystems nicht vollständig klären kann. Es gibt da einige Unwägbarkeiten. PHP-Dateien brauchen Leserechte für den Webserverprozess, wenn PHP als Modul ausgeführt wird. In anderen Systeme werden diese von einem FCGI-Prozess unter eigener Kennung ausgeführt. Da braucht dann der Webserver-User keinen Lesezugriff, besonders nicht, wenn das Framework außerhalb des DocumentRoot liegt. Statische Dateien hingegen benötigen üblicherweise nur Leseberechtigung für den Webserverprozess, solange nicht von PHP aus darauf zugegriffen werden soll.

Wie die Rechte auf den Zielsystemen gehandhabt werden, weiß man als Autor eines universell einsetzbaren Frameworks nicht und kann dafür kein Setup-Script schreiben, das all diesen Gegebenheiten gerecht wird, ohne übermäßig komplex zu werden.

dedlfix.

[TS]

Hello,

Es ist ja davon auszugehen, daß ein setup mit root Berechtigung ausgeführt wird.

Nein. Nicht jeder hat einen eigenen Server für sich. Man sollte auch davon ausgehen, dass nur eingeschränkte Nutzerrechte zur Verfügung stehen.

Auch unter dem Aspekt, dass hier ggf. ein fremdes Rahmenprogramm hinter der eigenen Anwendung steckt, würde ich das niemals als Root aktivieren/installieren. Wer weiß schon, was das Teil im Hintergrund dann alles anstellt? Kaum einer wird alle 100.000 Zeilen (und mehr) des Frameworks gelesen und verstanden haben.

Liebe Grüße
Tom S.

[TS]

Hello,

Es ist ja davon auszugehen, daß ein setup mit root Berechtigung ausgeführt wird.

Im Himmels Willen, wo lebst Du denn?
Insbesondere bei shared Hosting wirst Du garantiert keine Root-Berechtigung bekommen.

Ein PHP-Setup, wie auch immer die Daten auf den Server gelangen, sollte immer mit der Erkundung der Umgebung beginnen:

• Webserver-Version?
• aktueller Webserver-User (also der dem Domainnutzer zugewiesen wurde)
• Darf dieser User eigene Verzeichnisse und Dateien anlegen, wem gehören die dann, wie sind die Default-Rechte gesetzt? Die typischen "0777-Installationen" sind tunlichst zu vermeiden!
• welche PHP-Version läuft?
• läuft PHP als Modul oder als (Fast-)CGI?
• welche Verzeichnisse sind außerhalb der Document-Root vorhanden und nutzbar?
• welches Default-Character-Set ist eingestellt?
• funktioniert das Session-Management? (hier ist besonders spannend, ob und wann die Sessiondatei wieder gelöscht wird, bzw. ob ein schreibender Zugriff pro Request darauf notwendig ist, damit sie nicht zu früh wieder gelöscht wird)
• Datenbank vorhanden und besteht Zugriff?
• Darf das Script Datenbaneken, Tabellen, usw. anlegen
• sind alle notwendigen Zugriffsrechte für die Datenbank vorhanden, um alle verwendeten Features (z. B. Trigger deklaiereun und definieren, Trigger benutzen lassen, eigenen User mit eigeschränkten Rechten anlegen, usw.) vorhanden?
• usw.

Erst, wenn man diese Prüfpunkte in eine für seine Anwendung sinnvolle Reihenfolge gebracht hat und diese sinnvolle Ergebnisse gegeben haben, kann man die Anwendung entfalten und für die Benutzung einstellen.

.htaccess sollte man für Zugriffsrechte möglichst gar nicht verwenden müssen.

Liebe Grüße
Tom S.

[pl]

Ich bräuchte Struktur im Framework und vorgehensweise wie das strukturieren kann.

Das Thema hatten wir doch erst gestern oder? Zur Erinnerung: Verzeichnisstruktur und Nomenklatur.

seine Zugriffsrechte im Datensystem

Nein, ein Setup hat damit nichts zu tun. Zugriffsrechte sind einer Frage der Konfiguration und nicht eine Frage des Setup!

Inizialisierungen: Pfad Konstanten

Aha. Also mach das Setup konfigurierbar. Im Grunde genommen ist auch ein Framework nur eine Library die auf die Festplatte kopiert wird. In Perl würde das so ablaufen, also was der Installateur macht:

1. [./configure]
2. perl Makefile.PL
3. make
4. [make test]
5. make install

Das läuft über ein Makefile und das Make-Utility make was auf jedem System (außer Windows) verfügbar sein dürfte, ansonsten wird es nachinstalliert. Das Makefile wird anhand der Custom-Konfiguration auf dem Zielsystem erstellt, optional kann der Installateur ./configure vorher aufrufen um beispw. den Pfad zu setzen.

Der Aufruf make entpackt das Installationsarchiv in ein temporäres Verzeichnis, die sogenannte build-Lib, danach kann optional getestet werden (punkt 4). Erst make install kopiert die gesamte Library in das Zielverzeichnis.

So läuft das mit Perl-Libraries ab und was soll ich Dir sagen: Für ein PHP-Framework würde ich das ganz genauso machen, allenfalls ohne Perl, also nur über make und Makefile:

1. ./configure
2. make
3. make test
4. make install

Viel Erfolg.

[dedlfix]

Tach!

So läuft das mit Perl-Libraries ab und was soll ich Dir sagen: Für ein PHP-Framework würde ich das ganz genauso machen, allenfalls ohne Perl, also nur über make und Makefile:

Das ist eine für PHP untypische Vorgehensweise. Oder anders gesagt, ich habe noch kein PHP-Projekt gesehen, das make zum Installieren nimmt. Das kann man so machen und funktioniert auch beispielsweise für das Installieren von Betriebssystemkomponenten nach diesem Prinzip. Bei PHP muss man jedoch davon ausgehen, dass viele Nutzer keinen Shellzugriff haben und damit solche Kommandos nicht ausführen können. Deswegen gestaltet man seine Installationsroutine am besten so, dass einfaches Aufspielen mit FTP vorgenommen werden kann. Wenn weitergehende Installationsschritte (wie Datenbanksetup) stattfinden sollen, schreibt man ein PHP-Script, das über den Browser aufgerufen werden kann.

Eine weitere mittlerweile etablierte Vorgehensweise ist, ein Paket für Composer zu packen. Allerdings braucht man für dessen Anwendung wieder Shellzugriff.

dedlfix.

[Mitleser]

[...] In Perl würde das so ablaufen, also was der Installateur macht:

1. [./configure]
2. perl Makefile.PL
3. make
4. [make test]
5. make install

Auch unter Perl wäre das eher die letzte, und nicht die favorisierende Vorgehensweise. Unter unixodiden Systemen würde ich für Module immer zunächst die Paketverwaltung befragen und nach Möglichkeit über diese Installieren. Ansonsten über die CPAN-Shell: "perl -MCPAN -e 'shell'". Bei einfacheren Modulen kann auch ein simpler Upload reichen.