auch wir wurden gestern in der Nacht böse überrascht von diesem Problem und haben alle Shopware-Shops aktuell auf PHP 5.6 umstellen müssen.
Auf unserem Server sind die selben PHP Versionen (alt-php70-7.0.32-1) aktiv. Diese Version wurde jedoch bereits automatisiert am 30.10.2018 installiert und ist als kritisches Sicherheitsupdate vom PHP Hersteller gekennzeichnet.
Es sieht alles danach aus, dass Shopware ein Problem mit dieser PHP Version hat. Dies ist aber die aktuelle PHP7 Version, welche direkt vom PHP Hersteller stammt.
Was wir persönlich nicht verstehen ist, warum sich dieses Problem dann erst so erheblich zeitversetzt bemerkbar gemacht hat. Denn zwischen dem 30.10. und 7.11. liegen immerhin 8 Tage. Und in diesen 8 Tagen gab es keinerlei Veränderungen am Server.
Was jedoch einen Tag vorher tagsüber installiert wurde, war entweder das Update auf Version 5.5.3 bzw. der aktuellsten Version des Shopware Sicherheits-Plugin. Die üblichen Cronjob laufen immer in der Nacht ab und ab genau dann begannen diese Probleme.
Was jedoch einen Tag vorher tagsüber installiert wurde, war entweder das Update auf Version 5.5.3 bzw. der aktuellsten Version des Shopware Sicherheits-Plugin. Die üblichen Cronjob laufen immer in der Nacht ab und ab genau dann begannen diese Probleme.
Ich hatte das Problem gleich bei mehreren Kunden. Und da waren bis gestern unterschiedliche Versionen im Einsatz.
5.4.6 war die älteste Version und 5.5.3 die neuste.
Das Frontend habe ich mit einer aktuellen Datensicherung zum Laufen bekommen.
Ins backend komme ich komischerweise immer noch nicht rein:
The provided CSRF-Token is invalid. If you're sure that the request to path "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429" should be valid, the called controller action needs to be whitelisted using the CSRFWhitelistAware interface.
Time:
2018-11-08T17:27:12.441480+0100
Channel:
core
request:
{
"uri": "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429",
"method": "GET",
"query": {
"f": "m/Locale|v/Main|v/main/Form|store/Locale|c/Main",
"no-cache": "1541694429",
"module": "backend",
"controller": "Login",
"action": "load"
},
"post": []
}
shop:
No shop data available
session:
No session data available
CRITICAL
Message:
The provided CSRF-Token is invalid. If you're sure that the request to path "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429" should be valid, the called controller action needs to be whitelisted using the CSRFWhitelistAware interface.
Time:
2018-11-08T17:27:12.459490+0100
Channel:
core
request:
{
"uri": "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429",
"method": "GET",
"query": {
"f": "m/Locale|v/Main|v/main/Form|store/Locale|c/Main",
"no-cache": "1541694429",
"module": "backend",
"controller": "Login",
"action": "load"
},
"post": []
}
shop:
No shop data available
session:
No session data available
ERROR
Message:
Shopware\Components\CSRFTokenValidationException: The provided CSRF-Token is invalid. If you're sure that the request to path "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429" should be valid, the called controller action needs to be whitelisted using the CSRFWhitelistAware interface. in /home/amafinod/public_html/engine/Shopware/Components/CSRFTokenValidator.php:109
Stack trace:
#0 /home/amafinod/public_html/engine/Library/Enlight/Event/Handler/Default.php(91): Shopware\Components\CSRFTokenValidator->checkBackendTokenValidation(Object(Enlight_Controller_ActionEventArgs))
#1 /home/amafinod/public_html/engine/Library/Enlight/Event/EventManager.php(220): Enlight_Event_Handler_Default->execute(Object(Enlight_Controller_ActionEventArgs))
#2 /home/amafinod/public_html/engine/Library/Enlight/Controller/Action.php(176): Enlight_Event_EventManager->notify('Enlight_Control...', Object(Enlight_Controller_ActionEventArgs))
#3 /home/amafinod/public_html/engine/Library/Enlight/Controller/Dispatcher/Default.php(549): Enlight_Controller_Action->dispatch('loadAction')
#4 /home/amafinod/public_html/engine/Library/Enlight/Controller/Front.php(222): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
#5 /home/amafinod/public_html/engine/Shopware/Kernel.php(215): Enlight_Controller_Front->dispatch()
#6 /home/amafinod/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(486): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#7 /home/amafinod/public_html/engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
#8 /home/amafinod/public_html/vendor/symfony/http-kernel/HttpCache/HttpCache.php(253): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
#9 /home/amafinod/public_html/engine/Shopware/Components/HttpCache/AppCache.php(105): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true)
#10 /home/amafinod/public_html/shopware.php(122): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
#11 {main}
Time:
2018-11-08T17:27:12.460435+0100
Channel:
core
request:
{
"uri": "/backend/Login/load/?f=m/Locale|v/Main|v/main/Form|store/Locale|c/Main&no-cache=1541694429",
"method": "GET",
"query": {
"f": "m/Locale|v/Main|v/main/Form|store/Locale|c/Main",
"no-cache": "1541694429",
"module": "backend",
"controller": "Login",
"action": "load"
},
"post": []
}
shop:
No shop data available
session:
No session data available
Die Fehlermeldung und der Ladebalken sind imm er noch gleich, cache und cookies sind gelöscht:
Mal einen anderen Browser probiert, bzw. den Inkognito Modus? Dies ist sehr häufig der Fall, wenn ein alter CSRF Session Cookie noch vorhanden ist.
LG Andre
Hallo Andre,
darf ich mal fragen, was denn nun passiert um das eigentliche Problem mit dieser PHP 7 Version zu lösen?
Ich hatte mir das auf meiner Testumgebung mit indentischer PHP Version aus dem offiziellen Ubuntu-Repo angeschaut und konnte das nicht nachstellen. Gleiche gilt für eine Debian-Umgebung. Aktuell vermute ich eher, dass es hier an die verwendete Distribution liegt, da augenscheinlich alle CloudLinux einsetzen. Wir werden uns das aber morgen nochmal genauer anschauen.
@AndreHerking ich hab dir eine PN gemacht mit dem Link zu der PHPInfo
Es liegt im übrigen nicht am CloudLinux sondern am HardendedPHP. Bei einem anderer Hoster der CloudLinux im Einsatz hat aber kein HardendedPHP läuft alles normal.
@fm1985 Davon abgesehen dass dein Hoster mit der PHP Version „alt-php70-7.0.32-1.el7.x86_64“ ein Testing Release nutzt, würde ich mir einen anderen Hoster suchen.
@AndreHerking ich hab dir eine PN gemacht mit dem Link zu der PHPInfo
Es liegt im übrigen nicht am CloudLinux sondern am HardendedPHP. Bei einem anderer Hoster der CloudLinux im Einsatz hat aber kein HardendedPHP läuft alles normal.
Als Ergänzung:
Unser Hoster hat hierzu bei Cloudlinux angefragt und die Antwort erhalten, dass alle Php 7 (7.0/7.1/7.2) Versionen direkt aus den RPM Ressourcen von RedHat stammen.
Das hardened Php sind nur die älteren Versionen (5.6 und älter).
Es gibt auf einem Cloudlinux cPanel System auch keine Möglichkeit andere Php Versionen als die von Cloudlinux zu verwenden.
HardendedPHP nutzt ja nicht (mehr) supportet PHP Packages - wenn sich da noch Fehler befinden bzw. nicht mehr vorhandene Kompatibilitäten, kann es zu solchen Fehlern kommen. Wir berücksichtigen bei der Entwicklung natürlich die offiziellen PHP Packages in Kombination der gängigen Distributionen.
Ich würde euch empfehlen gemeinsam mit dem Hoster zu prüfen, ob hier nicht andere PHP Repositories genutzt werden können, die die gängigen Releaes nutzen.
für Dich zur Info die Antwort unseres Hoster auf Deinen letzten Beitrag:
Wie bereits mitgeteilt stellt CloudLinux HardenedPHP nur für die älteren PHP Versionen (5.6 und älter) bereit. Die 7er Versionen sind die offiziellen RPM Pakete von Redhat (EL6). Dies wurde so auch vom CloudLinux Hersteller bestätigt.
Interessant ist, dass die Shops ja derzeit mit PHP 5.6 arbeiten und diese Version nutzt das HardenedPHP. Der Shop läuft also derzeit mit einer nicht offiziellen Version fehlerfrei, aber mit der offiziellen Version von PHP 7 nicht:
Name : php70
Arch : x86_64
Version : 7.0.32
Release : 4.el6
Size : 2.7 k
Summary : PHP scripting language for creating dynamic web sites
An dem “h” in der Version ist das HardenedPHP zu erkennen.
Und CloudLinux ist ein 100% Ableger von CentOs. Beide basieren auf den Sources vom RedHat Enterprise Linux, was eine absolut gängige Distribution ist. Der Marktanteil von RedHat / CentOs Systemen ist deutlich höher als wie von Ubuntu auf Servern. Daher kann ich nicht nachvollziehen warum Shopware nur auf Ubuntu / Debian Systemen testet.
Der CloudLinux Hersteller verweist darauf, dass die 7er Version original vom Hersteller stammt und von denen nicht modifiziert wurde. Dementsprechend verweisen die bei PHP Problemen auf php.net und Shopware. Anders wäre es, wenn die 5er PHP Versionen betroffen wären, was aber nicht der Fall ist.
Nunja, Fakt ist aber auch, dass die gleiche Version (php 7.0.32) bspw. bei Profihost einwandfrei läuft und auch lokal bei mir. Habe ich beides schon durchgetestet. Local mit dem offiziellen Docker-Image von PHP. Also muss ja zwangsweise etwas mit dem Paket nicht stimmen.
Wenn du einmal den Blog von Cloudlinux liest weißst du direkt schon dass es kein Orginal Package von PHP mehr ist. СloudLinux Blog
alt-php70-7.0.32-3
ALTPHP-587: backported fixes from upstream PHP versions 7.1.23 and 7.2.11.
Die Backporten Fixes von PHP 7.1 / 7.2 in 7.0 rein. Das ist kein Standard PHP 7.0 mehr was von PHP selbst kommt. Davon abgesehen dass PHP 7.0 noch supportet wird, ist das ja mal total ein no go
Moritz, sorry. Aber was ist das denn für eine Antwort.
Ihr habt sehr detaillierte Informationen bekommen, von denen man doch erwarten kann das jetzt genauer zu prüfen.
Nein. Wenn es ein Problem ist, was nur in dieser Kombination auftritt und nicht mit den offiziellen Packages die PHP selbst ausliefert, werden wir uns das Problem auch nicht im Detail ansehen. Bei einem zertifizierten Hoster wäre das sicherlich etwas anderes, da wir dann auch in die Kommnunikation mit dem Hoster einsteigen. Also bleibt aktuell nur php5.6 nutzen oder mal auf Shopware 5.5 gehen und php7.2 probieren. Ob das dann bei diesem Hoster funktioniert, können wir nicht beurteilen. Wir sind eine Standardlösung die mit Standardpaketen getestet ist. Wir testen immer mit den offiziellen PHP-Paketen aus den gängigen Repositories und damit funktioniert es nunmal.
Und wie gesagt: Es funktioniert fehlerfrei auf meinem System, auf dem System eines zertfizierten Hosteres. Es wird also definitiv am Package selbst liegen, was auf diesem Host verwendet wird.
ALTPHP-587: backported fixes from upstream PHP versions 7.1.23 and 7.2.11.
Die Backporten Fixes von PHP 7.1 / 7.2 in 7.0 rein. Das ist kein Standard PHP 7.0 mehr was von PHP selbst kommt. Davon abgesehen dass PHP 7.0 noch supportet wird, ist das ja mal total ein no go
Danke für die Info. Das gebe ich einmal zurück an unseren Hoster.
Moritz, sorry. Aber was ist das denn für eine Antwort.
Ihr habt sehr detaillierte Informationen bekommen, von denen man doch erwarten kann das jetzt genauer zu prüfen.
Nein. Wenn es ein Problem ist, was nur in dieser Kombination auftritt und nicht mit den offiziellen Packages die PHP selbst ausliefert, werden wir uns das Problem auch nicht im Detail ansehen. Bei einem zertifizierten Hoster wäre das sicherlich etwas anderes, da wir dann auch in die Kommnunikation mit dem Hoster einsteigen. Also bleibt aktuell nur php5.6 nutzen oder mal auf Shopware 5.5 gehen und php7.2 probieren. Ob das dann bei diesem Hoster funktioniert, können wir nicht beurteilen. Wir sind eine Standardlösung die mit Standardpaketen getestet ist. Wir testen immer mit den offiziellen PHP-Paketen aus den gängigen Repositories und damit funktioniert es nunmal.
Und wie gesagt: Es funktioniert fehlerfrei auf meinem System, auf dem System eines zertfizierten Hosteres. Es wird also definitiv am Package selbst liegen, was auf diesem Host verwendet wird.
Shopware schiebt es auf den Provider und der Provider auf Shopware.
