Wichtig: Gründe für Ungültiger Anfrage-Token / Session-Fehler bei All-Inkl
Ich bin heute auf eine recht unerfreuliche Situation bei einem All-Inkl-Webspace aufmerksam geworden. Da der Fehler hier beim Webhoster, nicht bei Contao lag und die Situation imho ziemlich unglücklich ist, möchte ich hier darauf hinweisen. So laufen hoffentlich andere All-Inkl-Kunden nicht in den selben Fehler bzw. finden heraus, was sie tun müssen.
Wie fiel der Fehler auf:
Ich bekam heute morgen einen Anruf von Kunden, weil deren Kunden auf der Website beim Absenden eines Formulars ständig auf die Fehlermeldung "Ungültiger Anfrage-Token" von Contao kamen. Als ich mich für einen ersten Check ins Backend einloggen wollte, kam ich nicht hinein und erhielt auch hier nur die Token-Fehlermeldung.
Beim Contao-Check wurden vom Check selbst keine Fehler gefunden (valide Installation), aber rund um den Check herum erschienen Fehlermeldungen:
PHP-Code:
Warning: session_start():
open(/tmp/phpfpmsessions//sess_ed7920556ae07XXX, O_RDWR)
failed: No such file or directory (2) in /www/htdocs/wXXX/XXX.de/check/controller/bootstrap.php on line 27
Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at
/www/htdocs/wXXX/XXX.de/check/controller/bootstrap.php:27) in /www/htdocs/wXXX/XXX.de/check/controller/bootstrap.php on line 27
Warning: Unknown:
open(/tmp/phpfpmsessions//sess_ed7920556ae07XXX, O_RDWR)
failed: No such file or directory (2) in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp/phpfpmsessions/) in Unknown on line 0
Ich war sehr verwundert, da niemand von uns etwas am Webspace verändert hatte und auch in Contao nichts gemacht wurde. Die Website hatte bei früheren Tests einwandfrei funktioniert.
Was meinte All-Inkl dazu:
Ich schrieb eine E-Mail an support@all-inkl.com und erhielt die Antwort:
Zitat:
das entsprechende TMP-Verzeichnis war nicht vorhanden. Wir haben dieses nun angelegt. Das Problem sollte damit behoben sein.
Tatsächlich lief nun wieder alles. Ich war aber unzufrieden, denn ein Verzeichnis verschwindet mal nicht eben so. Ich wollte also wissen, wie es dazu gekommen war und rief beim Telefon-Support von All-Inkl an.
Die Dame am Telefon sah sich die Situation an und erklärte dann auf mein hartnäckiges Nachbohren, dass das Verzeichnis durch ein Sicherheitsupdate im Betriebssystem des Servers "verloren" gegangen war. Daraufhin wollte ich von ihr wissen, ob das jetzt nur bei diesem Projekt Pech war, oder theoretisch auch auf anderen Servern sein könne bzw. was All-Inkl von sich aus tut um zu verhindern, dass auch andere Kunden in dieses Problem laufen. Sie meinte darauf hin, All-Inkl könne da gar nichts tun. Es wäre nicht möglich, dass All-Inkl von sich aus prüft, ob ggf dieser Ordner auch auf anderen Servern fehlt (und dadurch dort auch solche Fehler hervorruft). Die Kunden müssten sich halt melden, wenn Fehler auftauchen.
Meine Meinung dazu:
Ich finde die Antwort von All-Inkl extrem unbefriedigend. Für mich bedeutet das, dass ich jetzt ernsthaft bei allen Kunden die Webspaces bei All-Inkl haben, nun Tests durchführen muss, ob dort möglicherweise das selbe Problem da ist. Abgesehen davon, dass mich das viel Zeit kostet (habe sehr viele Kunden zu All-Inkl geschickt), ärgert mich das Verhalten des Hosters an der Stelle. Der oben betroffene Kunde hat durch diese Situation schon richtig Ärger, weil so potentiell viele Anmeldungen für eine Veranstaltungen nicht durchgeführt wurden (da deren Nutzer von der Fehlermeldung abgeschreckt wurden). Erfahrungsgemäß meldet ja nur einer von X Nutzern, wenn er in Fehler läuft. Die anderen Nutzer ärgern sich und melden sich dann halt nicht an. Geschäft versaut.
Ich bin eigentlich ein großer Fan von All-Inkl, aber diesmal bin ich äußerst unzufrieden.
