PHP in anderen Dateiendungen als .php [GELÖST]

[mhagge]

Ich habe hier bei einem Kunden das Problem, dass PHP in .html-Dateien geparst werden soll.

Das übliche "Addtype usw" funktioniert mit Keyhelp anscheinend nicht, weil PHP als FPM ausgeführt wird (ich habe jedenfalls diverse Varianten ausprobiert, keine hat funktioniert)

Aufgrund eines irgendwo im Netz gefundenen Tips habe ich einfach die Konfiguration für PHP aus dem Apache gezogen und für ".html" in die .htaccess-Datei gepackt

Code: Select all

<FilesMatch "\.html$">
    SetHandler "proxy:unix:/run/php/keyhelp_xxxxx_php56.socket|fcgi://keyhelp_xxxx_php56.socket/
</FilesMatch>

Darauf gab es dann in den Error-Logs eine fehlermeldung bezüglich security.limit_extensions (es ist nur die Ausführung von .php-Dateien erlaubt)

Ich habe dann beim Benutzer in den PHP-Einstellungen

Code: Select all

security.limit_extensions = .php .html

eingefügt - leider ohne Erfolg. In der FPM-Conf-Datei der Domain wird daraus ein

Code: Select all

php_value[security.limit_extensions] = .php .html

Nun habe ich in die fpm-conf-Datei einfach

Code: Select all

security.limit_extensions = .php .html

eingegeben und den FPM neu gestartet - siehe da, damit funktioniert es. Nur ist es so ja nicht mehr Updatesicher - klar, man kann die Datei mit chattr +i gegen überschreiben schützen (habe ich nun auch getan), aber besonders elegant ist das nicht, finde ich.

Gibt es da evtl. einen einfacheren, insbesondere Update-sicheren Weg?

[select name from me;]

Alternativ könnte man die PHP Dateien mit der Endung .php hinterlegen und per Mod Rewrite einfach umbiegen.

Grob und ungetestet:

Code: Select all

RewriteEngine on 
RewriteBase / 
RewriteRule ^(.*).html$ $1.php

[mhagge]

Danke für den Tipp - in die Richtung hatte ich als erstes auch gedacht - nur, die Dateien kommen als .html aus einem CMS raus (enthalten aber u.a. PHP).

In der Standard .htaccess, die mitgeliefert wird ist auch dieses "Addtype usw. .html" vorhanden, auf dem alten Server hat das auch out of the Box funktioniert (ich habe den Kunden auf einem Keyhelp-Server umgezogen, deswegen stellt sich das Problem gerade), hier ging es mit den verschiedensten Variante nicht (wie gesagt, der Unterschied ist denke ich die PHP-FPM-Konfiguration)

[Tobi]

Du kannst einen Root-Cronjob einrichten welcher nach Änderungen an der Datei deine Anpassungen wieder hinzufügt.

Ansonsten könnte man das CMS an sich noch patchen.
Welches wird denn verwendet?

[mhagge]

Das CMS ist Perch.

Patchen würde ich es aber nicht wollen - ich bin nur der Webhoster, der seine Server umziehen will

Es müsste mal geupdatet werden, so wie ich das sehe - das will der Kunde aber nicht mehr(die Gründe kann ich allerdings teilweise auch nachvollziehen - es ist gerade so eben noch vertretbar und der Kunde wird sein Geschäft sehr wahrscheinlich im Laufe des Jahres 2019 aufgeben, dann wird die Webseite gar nicht mehr gebraucht ).

Nun könnte man sagen, dass das Problem sich dann ja auch von alleine erledigt - zu einem gewissen Grad stimmt das auch, aber zum einen: wer weiß ob ich nicht noch ähnliche Fälle bei den weiter anstehenden Umzügen finde, zum anderen ist das ja vielleicht auch für andere interessant (so exotisch ist der Fall, dass man .html als .php parsen will ja nun auch wieder nicht, denke ich)

[mhagge]

Vielleicht noch ein kurzer Nachtrag, warum ich den Kunden überhaupt umziehe (die Frage könnte man sich dann ja stellen ):

Das ist ein guter Freund von mir, mit dem ich abgesprochen hatte dass ich anhand seiner Webseite den Umzug teste Insofern ist das auch ganz gut, dass das nicht völlig problemfrei ging, das war durchaus Sinn und Zweck des Testes

[Tobi]

Laut https://docs.grabaperch.com/perch/getti ... xtensions/ ist aber die Dateiendung .PHP Standard.

Eventuell kann man die Umstellung auf HTML rückgängig machen?

[mhagge]

Wie gesagt, an der Seite will ich eigentlich nichts machen - ausser sie 1zu1 auf den neuen (Keyhelp)-Server übertragen. Ich hab sie seinerzeit auch nicht gemacht

[Fiesi]

schau mal hier,

das hatte mir auch mal geholfen da ich ein ähnliches problem mal hatte

https://stackoverflow.com/questions/468 ... -php-files

[select name from me;]

Als üblen Hack könntest Du alle Anfragen an eine HTML Datei per Mod Rewrite an eine PHP Datei umleiten, die dann die HTML Datei per include einbindet.

[Enigma]

Ich habe dann beim Benutzer in den PHP-Einstellungen

Code: Select all

security.limit_extensions = .php .html

eingefügt - leider ohne Erfolg. In der FPM-Conf-Datei der Domain wird daraus ein

Code: Select all

php_value[security.limit_extensions] = .php .html

Prinzipiell kannst Du dafür eine Datei namens .user.ini in den Document Root der Domain legen, die die von Dir gewünschten php.ini-Änderungen enthält. Diese werden dann auch in die Unterverzeichnisse "vererbt".

Bei mir funktionierte die Vererbung zunächst nicht. Laut Support (Alexander himself) gibt es einen Fehler bei Servern mit Debian 9 sowie Ubuntu 18. Dieser wurde intern bereits behoben und wird mit der nächsten KeyHelp-Version ausgerollt. Ich habe den Patch bei mir aber bereits im Voraus einspielen lassen, sodass das Feature auf meinem Ubuntu-18-System nun problemlos funktioniert.

Gruß
Jan

[mhagge]

Ah, das klingt schon besser, Danke für den Tipp!

Hier ists in der Tat en Debian 9, aber mich denke extra vorab patchen brauchts dann auch nicht - erstmal hoffe ich, dass es bis zur nächsten Version nicht mehr soweit hin ist, zum anderen funktioniert mein Workaround mit schreibgeschützter Config soweit ja bzw. würde sowieso erst bei einem Update evt. problematisch werden.

Also mal auf Wiedervorlage bis nach Keyhelp-Update legen

[mhagge]

Jetzt wollte ich das nach dem Update mal angehen - aber geht auch nicht (hätte ich aber auch selber drauf kommen können)

security.limit_extensions gehört auch im Original nicht in die php.ini, sondern in die fpm-Configuration. Dort kann man zwar im Prinzip auch Einstellungen der php.ini setzen, aber andersrum geht es halt nicht. Von daher kann man das auch mit funktionierender .user.ini nicht über die .user.ini setzen