nicht angemeldet
Re:
Dem stimme ich ja sogar zu. Wenn es um Direktiven geht, die nicht mit ini_set() manipuliert werden können, wird ein kluger Programmierer mit ini_get() Fallunterscheidungen im Steuerfluss einbauen, da er weiß, dass er sich nicht darauf verlassen kann, die Möglichkeit externer Konfigurationsdateien zu haben.
Oder sich diesen zusätzlichen Aufwand sparen, und eine gewisse Konfiguration einfach als Systemvoraussetzung festlegen.
Du siehst die Zwickmühle der Portabilität also immer noch nicht…
Damit haben wir bereits den ersten konfigurativen Vorfall, wo .user.ini gar nicht genutzt werden kann. Und ich glaube, dass ich mir das Repetieren allein für den Apachen von Direktive AccessFileName und AllowOverride ersparen kann. Jedoch sollte Dir mal langsam klar werden, dass andere Webserver das Konzept verzeichnisweiter Konfigurationsdateien gar nicht kennen.
Ist egal, ob der Webserver das kennt - wenn PHP auf eigene Faust nach einer lokalen Konfigurationsdatei sucht.
Warum dringt bei Dir nicht durch, dass PHP als Servermodul keine .user.ini interpretiert? PHP kann als Modul folgender Server gebaut werden:
AOLserver, Apache, Caudium, Continuity, litespeed, phttpd, Pi3Web, Roxen, thttpd, TUX, WebJames, Zeus
So, und nun erzähle mir mal bitte, wie Du bei einem von denen .user.ini-s nutzen willst!
Es gibt auch Situationen, in denen du ini_set nicht nutzen kannst.
Richtig. Es ist durchaus denkbar, das jemand ini_set() per disable_functions sperrt; nur betrachte mal die Wahrscheinlichkeit dieser Option gegen das recht sinnvolle Unterbinden von .user.ini-Konfigurationen!
Warum sollte das eine unwahrscheinlicher sein als das andere?
Wenn mir als administrativem Verantwortlichen für eine PHP-Installation die Möglichkeit, dass Nutzer gewisse Konfigurations-Optionen überschreiben, nicht gefällt, dann muss ich dafür sorge tragen, dass dies auf beiden Wegen - per ini_set, oder per verzeichnislokaler Konfigurationsdatei - unterbunden ist. (Das ist kein schwarz-weisses Ja oder Nein, sondern kann für einzelne Optionen durchaus unterschiedlich ausfallen.)
Da portable Konfiguration ausschließlich mittels ini_set() bewerkstelligt werden kann, würde ein Sperren dieser Funktion Deine Webspace-Nutzer »nicht sehr glücklich« machen. Demgegenüber steht aber der Fakt, dass unter vielen Umständen .user.ini-Konfigurationen nicht möglich sind, ohne dass hier konfigurativ eingegriffen werden muss. Du setzt bei Deiner Wahrscheinlichkeitsbewertung eine Methode, die immer verfügbar ist und explizit gesperrt werden muss, mit einer anderen Methode gleich, die unter vielen Konstellationen potenziell überhaupt nicht verfügbar ist.
Du schreibst etwas von schwarz-weiß, abber alleine da fängt es doch schon an, dass Du dann zwingend vor einem Apachen sitzen musst. Kein anderer Server lässt Konfigurationen per php_admin_(flag|value) zu. (Ja, Schwarz hast Du nämlich von vornherein ganz selbstverständlich unter den Teppich gekehrt.) Darüber hinaus muss es dann auch noch ein Modul sein, weil bei (Fast-)CGI hast Du nur Schwarz oder Weiß. Du kannst dort nicht einige Direktiven sperren - nur komplett ini_set().
Wenn ich aber entschieden habe, bestimmte Optionen durch den Nutzer überschreiben zu lassen - warum sollte ich das dann nur auf dem einen Wege zulassen, den anderen aber untersagen?
Du beschränkst Deine Betrachtung nur auf einen einzigen Spezialfall: Apache mit PHP-Servermodul.
Gruß aus Berlin!
eddi