"The resource owner or authorization server denied the request" Fehler im Log

Shopware 6 (German)
1

Hallo, seit ein paar Tagen ist extrem gehäuft dieser Fehler in den Logs zu finden.

[2023-04-04T14:22:14.299940+00:00] request.CRITICAL: Uncaught PHP Exception League\OAuth2\Server\Exception\OAuthServerException: "The resource owner or authorization server denied the request." at /home/xxxx/public_html/shopware6/vendor/league/oauth2-server/src/Exception/OAuthServerException.php line 243 {"exception":"[object] (League\\OAuth2\\Server\\Exception\\OAuthServerException(code: 9): The resource owner or authorization server denied the request. at /home/xxxx/public_html/shopware6/vendor/league/oauth2-server/src/Exception/OAuthServerException.php:243)\n[previous exception] [object] (Lcobucci\\JWT\\Token\\InvalidTokenStructure(code: 0): The JWT string must have two dots at /home/xxxx/public_html/shopware6/vendor/lcobucci/jwt/src/Token/InvalidTokenStructure.php:13)"} []

Es ist bei 2 Shops mit 6.4.18.1 und auch bei zwei Shops mit 6.4.20.0 zu beobachten. Da mehrere voneinander unabhängige Shops betroffen sind, wundert mich es etwas. Alle liefen vorher ohne Probleme und es wurden bis auf die Shopware-Updates keine Änderungen vorgenommen.

Ich konnte jetzt nicht wirklich eine Einschränkung der Funktion der Shops feststellen, aber allein die Anzahl der Fehler ist schon etwas nervig.

2 Likes
2

Das kann ich bestätigen! Mir ist das auch heute aufgefallen. Es sieht so aus, als ob alleine die Anzahl der Anfragen in einem Sciptlauf diesen Fehler verursacht. Wenn ich per Script (PHP) eine einzelne Anfrage stelle, klappt alles. Wenn ich, bei uns den gesamten Artikelstamm, an die Api übertrage, klappen die ersten x Anfragen und danach kommt der o.g. Fehler. Wir haben hier die 6.4.20.0

tomquenten

3

Hallo die Meldungen hatte ich massenhaft, bei einem Kundenshop.
Im Serverlog gab es diese Meldung:
„POST https://www.example.de/api/_action/message-queue/consume HTTP/2.0“ 500 110 „https://www.example.de/admin“ „Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0“
Nach dem ich das Plugin Shopware Store deaktiviert und aktiviert habe, ist Ruhe!

Frohe Ostern gewünscht!
Steffen Winde

1 Like
4

Same here, gibt es dazu Neuigkeiten?

5

Ich habe einmal getestet das Store-Plugin zu deaktiveren. Aber das scheint keinen Effekt gehabt zu haben.

6

Die gleichen Probleme treten auch bei unserem SW6-System auf: Version 6.4.20.0

7

Wir haben auch das Problem, deaktivieren Shopware Store Plugin hat Abhilfe gebracht.

8

Also das deaktivieren des Shopware Store Plugin schaffte KEINE Abhilfe. Ich habe jetzt einen Anfragecounter mitlaufen lassen. Es können 861 Anfragen gestellt werden, ab der 862 Abfrage kommt der o.g. Fehler zurück. Auch habe ich TESTWEISE das Shopware 6 Sicherheits-Plugin deaktiviert - ohne Erfolg.

Gibt es sowas wie eine SessionTime pro Api Aufruf? Oder eine Begrenzung wie viele Api Anfragen pro Sekunde / Minute gestellt werden dürfen?

Noch jemand Ideen?

tomquenten

9

Heute konnte ich 1168 Anfragen stellen, ab der 1169 Anfrage kam wieder die Fehlermeldung…

The resource owner or authorization server denied the request.

Damit dürfte die Begrenzung pro Sekunde / Minute obsolet sein…denke ich.

Weitere Ideen?

tomquenten

10

Gibt es dazu schon ein Ticket?

11

Von mir nicht, ich weiß nicht wie das geht, habe ich noch nie gemacht.

12

Bei uns gibt es das gleiche Problem. Bei zu vielen ausgeführten API Requests wird der Fehler gefeuert.

13

Habe das selbe Problem. Heute schon 9.200 Logeinträge.

Shopware: 6.4.19.0
PHP: 8.0

14

Wir haben dies auch. Gibt es Neues dazu bzw. befasst sich Shopware schon damit?
@marco.steinhaeuser

15

Shopware (Entwicklung) kann sich damit befassen, wenn es einen Bugreport dafür gibt. Wisst Ihr, wie das geht? Ansonsten kann ich das gern einmal beschreiben oder zeigen.

16

Ich hab mir das heute nochmal angeguckt. Hier sind es gerade die Frosh-Tools, die im ausgeloggten Zustand, weiterhin Anfragen an die API senden (health-status) und dabei „Bearer false“ im Header haben. Wenn man also im ausgeloggten Zustand einfach weiterhin Abfragen gegen die API sendet und getBasicHeader() des Api-Service verwendet, ist es schon mal ein Weg diesen Fehler zu produzieren. „false“ ist eindeutig an nicht valider Token.

Ich beobachte aber noch weiter.