Subunternehmer des Kunden aus der Hölle

[dedlfix]

Tach!

ist das so in der PHP-welt, dass man da immer gleich an .ini denkt? nur so nebenbei gefragt. oder gibts auch yaml?)

Hottis Welt ist Perl. Abgesehen davon, ist es in PHP sehr einfach, eine ini-Datei in einem Zug in ein Array zu bringen. XML geht auch als Konfigurationsdatenquelle, ist aber selbst mit SimpleXML deutlich komplexer zu bedienen. JSON hat ebenfalls eingebaute PHP-Unterstützung, YAML (noch) nicht (im Core, erst PECL).

ich sage nur: wenn die sorge davor, dass eine config-datei über den webserver auslesbar sein könnte, der grund ist, auf configs zu verzichten bzw. davor zu warnen, dann hast du mein mitleid.

Lösungen sollten immer an die Umstände angepasst sein. Die Erfahrung sagt, dass oftmals bei den Hostern kein Platz außerhalb des DocumentRoots vorhanden ist oder die Nutzer das System nicht auf diese Weise zu konfigurieren in der Lage sind. Große populäre Projekte tragen diesem Umstand Rechnung, sie müssen das, weil sie sonst in Support- und "geht nicht"-Meldungen ersticken. Beispielsweise haben Wordpress und Joomla immer leere index.html-Dateien in den Verzeichnissen, die nur für nicht direkt aufrufbare Code-Dateien vorgesehen sind. Die bessere Konfiguration wäre, diese Library-Pfade außerhalb des Docroots abzulegen. Das ist aber so nicht auf allen Systemen installierbar. Selbst das Ausschalten des Directory-Listings kann man nicht voraussetzen. Der Kompromiss ist dann eben die leere index.html, damit man wenigstens ein wenig Sicherheit hat. Wenn man nun mit dem Prinzip "Nur-Code (und Configs) außerhalb des DocumentRoot lagern" daherkommt, ist man auf vielen Systemen nicht verwendbar. Das Prinzip ist zwar generell gut, aber hier eben nicht. Deshalb ist es nicht sonderlich sinnvoll, nur nach Prinzipien zu entscheiden und zu handeln und alles andere nicht mehr zu bedenken. Und genausowenig ist es gut, lediglich die Prinzipien zu vertreten und alles andere auszublenden. Das ist der hauptsächliche Kritikpunkt an Hottis Argumentation.

Configs gehören nicht ins document root.
Und auch hier gibt es Server, die das nicht zulassen. Da nimmst du das Sicherheitsloch dann einfach in kauf, ist ja nicht dein Problem, oder?
Ich nehme überhaupt kein Sicherheitsloch in Kauf.

In aller Regel kann man davon ausgehen, dass - sofern PHP-Unterstützung generell vorhanden ist - *.php-Dateien nicht ungeparst ausgeliefert werden. Bei anderen Dateiendungen kann man das nicht voraussetzen. Und man kann auch nicht voraussetzen, dass der Anwender sich das System ordentlich konfiguriert, selbst wenn man Handlungsanweisungen dazu in die README schreibt. Wer ist nun der Böse, wenn das System leicht hackbar ist? Der Programmierer natürlich, wer sonst? Es ist hier einfach der bessere Kompromiss, die Konfigurationswerte in PHP-Dateien vorzuhalten. - Hat man die volle Kontrolle über das System und die sicherheitstechnisch-administrative Ahnung, dann sollte man das selbstverständlich ordentlich aufsetzen. Leider sind manche Anwendungen zu sehr auf die oben genannten schlechten Voraussetzugnen getrimmt und lassen sich nicht so einfach aufteilen.

Ernsthafte Dinge hostet man nicht auf Billig-Servern, in denen alles im doc root liegen muss.

Schönes Prinzip. Scheitert aber nicht selten an den unverhandelbaren Gegebenheiten.

Falls man sich aus irgendeinem Grund mal mit solchen Begebenheiten rumschlagen muss, tut man das, was in der Situation notwendig ist.
Ich halte nichts davon, zu generalisieren. Weil ein Skript laut deiner Aussage ohne jegliche Änderung auf allen erdenklichen Servern laufen sollte, sollte man auf Configs verzichten, weil die Möglichkeit besteht, dass es Server gibt, auf denen configs über HTTP auslesbar sind. Das kann doch nicht ernsthaft eine Leitlinie zum Programmieren sein.

Sehr gut, du kannst also doch situationsbedingt entscheiden und stellst die Prinzipien, egal wie gut sie unter Idealvoraussetzungen aussehen mögen, nicht über alles. Dann ist ja zumindest aus meiner Sichts noch nicht alles verloren. ;-)

dedlfix.