allow_url_fopen On

Wie der Zufall es so will, hat mein Provider vor einigen Tagen einen Serverumzug durchgeführt. Natürlich habe ich das Ereignis in einer Mail angekündigt bekommen, also nichts wirklich Schlimmes. Da ich seit Wochen mit Googles-Sitemaps herumkämpfe (aktuelle Sitemaps werden nicht verarbeitet, alte Informationen noch Monate lang gecrawlt), schau ich alle paar Tage einmal bei meinen Sites vorbei, um zu sehen, ob die angeblich von Google nicht erreichbaren Links gehen (was sie natürlich tun :). Ups! Und da zeigt mir der Firebug doch JavaScript-Fehler bei meiner cms4xml.wkow.de-Site an. Was ist da los? Die Verarbeitung des Atom-Feeds von Heise läuft ins Leere ... Schnell mal auf dem lokale Spiegel der Site nachvollzogen: Hier ist alles im Lot. Dann kurz die URL direkt in der Zeile getestet. Fehlermeldung: URL file-access is disabled in the server configuration ... irgendwie wird die URL nicht eingelesen und der Feed nicht geladen ...

Der Vergleich der PHP-Konfigurationen per phpinfo() zeigt recht schnell eine Differenz bei dem Konfigurationsparameter allow_url_fopen: auf dem lokalen Host ist der Wert On ; beim Provider Off.

Erster Gedanke: Das lässt sich sicherlich per ini_set("allow_url_fopen",1); im PHP-Skript beheben. Geht nicht! In der PHP-Dokumentation kann man lesen, dass sich dieser Parameter nur in der php.ini oder httpd.conf verdrehen lässt. Was tun? Mal googlen, ob Leidensgenossen ähnliche Probleme haben und vor allem auch schon Lösungen. Ja, es gibt diverse Schilderungen und auch Ratschläge. Unter anderem der Vorschlag, es mal in der Datei .htaccess mit dem Eintrag php_value allow_url_fopen 1 zu versuchen. Aber das führt bei mir nur zu einem Internal Server Error 500. Weitere Vorschläge sind, es mittels Socketfunktionen oder CURL zu probieren.

Und dann endlich ein entscheidender Hinweis: PHPSuExec wird von Apache-Servern, die PHP nicht als Modul, sondern als CGI ausführen, verwendet.

PHPSuExec provides the facility to have all scripts running the relevant user account instead of under the Web Servers account. This facility allows the server Administrators to isolate and manage malicious or runaway script usage very quickly, avoiding unwanted or un-authorised scripts from running for a lengthy period of time. ... Under phpSuExec configurations, PHP running as a CGI with "suexec" enabled (su = switch user, allowing one user to "switch" to another if authorised) - Your php scripts now execute under your own user/group level. Files or directories that you require your php scripts to be able to write to no longer need to have 777 permissions. ... Now, when PHP is running as a CGI and phpSuExec protected, manipulating the PHP settings is still possible. You will now be creating and using your own "Local php.ini" file to manipulate the desired php settings. ... In many cases, you might need to have multiple copies of the same php.ini file in different directories, unlike .htaccess files, php.ini files are not applied recursively to lower directories. [hier gefunden]

Und es funktioniert! Schnell eine php.ini mit folgendem Inhalt allow_url_fopen=1 angelegt und alles läuft wieder so wie gehabt.

Anmerkung: Es wird recht kontrovers diskutiert, ob allow_url_fopen On ein Sicherheitsrisiko darstellt oder nicht. In dem hier zur Diskussion stehenden Fall wird eine XLM-Strecke (Atom-Feed von Heise) angefordert und als DOMDocument-Objekt aufgebaut, welche dann um ein vorgegebenes XSL-Stylesheet angereichert und via XMLHttpRequest() als modifizierte XML-Strecke an den Client übersandt wird. Der Browser jagt das Erhaltene durch seinen XSL-Prozessor und stellt es dar. Ein Angriff könnte hier eigentlich nur durch die DOMDocument-Methoden 'load' und 'saveXML' erfolgen; im Moment gehe ich davon aus, dass diese sicher sind.