Hi,
Aber wenn solche Konfigurations-Einstellungen als ausführbarer Code gespeichert werden, besteht immer auch die Möglichkeit, unerwünschten Code in diese Dateien zu packen. Das muss nicht unbedingt ein Hacker-Angriff sein, ein dummer Zufall, ein Versehen reicht eventuell schon. Oder eine dynamisch erzeugte Anweisung ist syntaktisch falsch, und schon bricht das gesamte Script ab.
Das hat für mich jetzt erst mal nichts mit der Art der Verarbeitung der (Config-)Datei zu tun sondern mit der Validierung der Daten (vor der Abspeicherung in der Config-Datei).
das ist die eine Seite der Medaille. Aber die Datei kann ja auch verändert oder ersetzt werden, *nachdem* sie einmal korrekt erzeugt wurde.
Solche Informationen nur als reine Daten speichern, und programmgesteuert lesen und auswerten. Das geht schon recht komfortabel, wenn man beispielsweise das ini-Format verwendet.
Aber das parsen einer ini-Datei ist doch bestimmt langsamer als das "normale" Einlesen der PHP-Datei (oder?).
Ich hab's nicht ausprobiert, aber ich denke, dass die ini-Datei sogar die Nase vorn hat. Denn eine Include-Datei mit PHP-Code muss auch erst vom Parser analysiert und im Arbeitsspeicher compiliert werden, der Vorgang braucht auch Zeit.
Und gerade der Lese-Vorgang einer Datei die überall benötigt wird sollte doch schnell gehen.
Ja. Und da bin ich überzeugt, dass das Lesen und Interpretieren einer auf das Datenformat optimierten Datei (muss nicht das ini-Format sein, das war nur ein Beispiel) schneller geht, als das Lesen, Analysieren und Übersetzen von Programmcode.
Ciao,
Martin
Der geistige Horizont ist der Abstand zwischen Brett und Hirn.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(