Wichtig: Gründe für Ungültiger Anfrage-Token / Session-Fehler bei All-Inkl

[Nina]

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:

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:

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.

[Kahmoon]

Hmm irgendwie hab ich es noch nicht ganz verstanden. Wenn es ein Ordner im eigenen Browser ist, kann All-Inkl. doch nichts dafür!? Oder umgekehrt...wie kann ein Sicherheitsupdate vom Browser ein Verzeichnis auf dem Server löschen!?

Ich habe 95% meiner Installationen bei All-Inkl und hatte das Problem noch nie.

[Nina]

Kein Ordner im regulären Kundenverzeichnis. Ein Ordner am Server (Root-Ebene, Kunde hat da keinen Zugriff).

[Kahmoon]

OK, also ein Sicherheitsupdate an deren Webserver. Das Wort "Browser" hat mich irritiert.

[Nina]

OK, also ein Sicherheitsupdate an deren Webserver. Das Wort "Browser" hat mich irritiert.

Jau, Schreibfehler von mir. Sollte natürlich "Server" statt "Browser" sein. Hab ich korrigiert

Und ja, abgesehen von der heutigen Situation bin ich sonst auch mit All-Inkl zufrieden. Wahrscheinlich bin ich so genervt, weil ich sonst einfach einen besseren Stil von ihnen gewohnt bin.

[tab]

Also das würde ich als All-Inkl-Kunde, der ich nicht bin, als höchst unbefriedigend empfinden. Vor allem die Antwort, dass All-Inkl da von sich aus nichts prüfen kann. Das ist ja wohl eine Lachplatte. Damit verglichen ist sogar 1&1 noch kompetenter. Nicht nur können die das prüfen, es ist ihre verd***te Pflicht. Wenn ich an der Serverkonfiguration irgenwas ändere, dann prüfe ich doch, ob alles noch funktioniert. Oder betrachten die ihre Kunden als Betatester? Das letzte ist wohl eher eine rhetorische Frage .

[Ainschy]

Hallo Nina,

ich habe verschiedene Installationen durchgesehen und konnte nur bei meiner 4 Einträge vom 9.6. mit dem tmp/session Fehler finden. Kann es sein das AI bereits gehandelt hat oder nur bestimmte Pakete betroffen sind?

[soweit_ok]

... dass das Verzeichnis durch ein Sicherheitsupdate im Betriebssystem des Browsers "verloren" gegangen war.

Das war ja ne seltsame Schlussfolgerung von besagter Support-Dame. Ist mir schleierhaft, was der Browser mit einem Ordner mit dem /tmp Ordner auf dem Server zu tun haben soll.

Das fast exakt gleiche Problem, das der an die Variable session.save_path zugewiesene Ordner nicht mehr existierte, gabs vor ca. 2 J. bei einem meiner Kunden auch schonmal. Gehostet von einem kleinen Dienstleister, der Reseller bei All-Inkl ist. Der einzige Unterschied - die Webseite, seinerzeit noch Cto. 2.11.17, war garnicht mehr erreichbar. Weil sich dieser Dienstleister zu dem Zeitpunkt leider erst 3 Tage später zurückmeldete, musste ich was tun. Ich konnte zwar selber feststellen, dass der gesetzte Pfad nicht mehr existierte, es mangels nötiger Rechte aber nicht ändern. Mir gelang ein Workaround, der in einem solchen Fall Probleme der Webseite verhindert. Leider erinnere ich mich nicht, was ich dagegen tat, schon zu lange her. Auch erfuhr ich nie, was denn eigentlich die Ursache für den verschwundenen Ordner gewesen war, bzw. ebenfalls nur diffuse Auskünfte, mit denen ich nichts anfangen konnte. Scheint jedenfalls bei All-Inkl. nicht neu zu sein.

Nachtrag: Ist bei All-Inkl. evtl. eine .user.ini oder ähnlich verfügbar, womit man einige Variablenwerte der php.ini überschreiben kann? Dann war vllt. das meine Hilfslösung, aber ich weiß es wie gesagt nicht mehr.

Nachtrag 2: Ups, inzwischen klärte sich, "Browser" war ein Tippfehler. Hab mich schon schwer gewundert.

[Nina]

Kann es sein das AI bereits gehandelt hat oder nur bestimmte Pakete betroffen sind?

Ja, es trifft nur bestimmte Konstellationen. Aber welche das sind, konnte/wollte sie mir nicht sagen. Sie meinte halt, dass sie das deshalb nicht generell "im Gießkannenprinzip" überall korrigieren könnten. Aber der Aufwand des Testens bleibt jetzt halt an den Kunden hängen, was mich ärgert.

[Nina]

Ist bei All-Inkl. evtl. eine .user.ini oder ähnlich verfügbar, womit man einige Variablenwerte der php.ini überschreiben kann?

Soweit ich weiß, könnte man im Webspace-Root in der .htaccess einen Pfad zu nem neuen Ordner (CHMOD 777) setzen

php_value session.save_path /www/htdocs/wXXX/tmp-test/

Habe es aber nie getestet.

[soweit_ok]

... Vor allem die Antwort, dass All-Inkl da von sich aus nichts prüfen kann. ...

Na ja, manchmal ist es allerdings bloß ein noch wenig erfahrenen neuen Supportmitarbeiter, der sich nicht zuzugeben traut, etwas nicht zu wissen. Somit nicht dem ganzen Unternehmen anzulasten. Wenn ich sowas merke, (sofern der/diejenige nicht pampig wird) bitte ich normalerweise einfach darum, mich mit einem Kollegen zu verbinden, dem vielleicht noch mehr zu diesem Thema bekannt ist.