Bug #301
offen[Bugsink] InvalidArgumentException: The offset must be a positive integer
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/3c92831a-5c60-48fb-9b45-834be5c37d16/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
InvalidArgumentException: The offset must be a positive integer
Automatisch erstellt durch n8n
KI-Analyse:
Analyse des Fehlers: InvalidArgumentException: The offset must be a positive integer
¶
1. Ursache identifizieren¶
Der Fehler entsteht im TYPO3 Core-Middleware-Stack, konkret im Bereich der Request-Verarbeitung. Die Aufrufkette zeigt:
VerifyHostHeader::process() → NormalizedParamsAttribute::process() → ResponsePropagation::process()
Wahrscheinlichste Root Cause:
Der Fehler tritt auf, weil die trustedHostsPattern-Konfiguration in $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] entweder nicht gesetzt, leer oder ungültig ist. Wenn VerifyHostHeader::process() (Zeile 55) versucht, den Host-Header des eingehenden Requests gegen dieses Pattern zu validieren (vermutlich mittels preg_match), schlägt die Validierung fehl oder liefert kein erwartetes Ergebnis-Array. Anschließend versucht NormalizedParamsAttribute::process() (Zeile 44), auf ein Array-Element mit einem nicht-positiven Integer-Offset zuzugreifen – z. B. weil ein preg_match-Ergebnis leer ist oder ein Rückgabewert null/false ist und als Array-Index verwendet wird.
Konkretes Szenario:
// In NormalizedParamsAttribute::process() oder aufgerufener Methode:
// Ein Array wird mit einem Offset accessiert, der kein positiver Integer ist
// z.B. durch fehlende/null Werte aus der Request-Parametrierung
$request->getAttribute('normalizedParams')[$invalidOffset]; // $invalidOffset ist kein int > 0
Dies ist kein Extension-Bug, sondern ein TYPO3 Core-Problem (cms-core), das durch fehlende/mismatchende Konfiguration ausgelöst wird.
2. Fix (konkret)¶
Schritt 1 – trustedHostsPattern konfigurieren:
In der LocalConfiguration.php oder über das Install Tool sicherstellen:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] = '.*';
(Oder ein spezifisches Regex-Muster entsprechend der Domain verwenden, z. B. '^www\.example\.com$')
Schritt 2 – Host-Header prüfen:
Stellen Sie sicher, dass der eingehende HTTP-Request einen gültigen Host-Header enthält. Fehlende oder leere Host-Header (z. B. bei CLI-Requests oder falsch konfigurierten Reverse-Proxies) lösen diesen Fehler aus.
Schritt 3 – Site-Configuration prüfen:
Überprüfen Sie die Site-Configuration unter config/sites/<siteIdentifier>/config.yaml:
base: 'https://www.example.com/'
baseVariants: ~
Stellen Sie sicher, dass base gesetzt und korrekt ist.
Schritt 4 – (Workaround falls Core-Bug):
Falls nach Konfigurationskorrektur der Fehler weiterhin besteht, kann ein temporärer Workaround in public/index.php vor dem Bootstrap helfen:
// Vor dem Bootstrap:
if (empty($GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'])) {
$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] = '.*';
}
Langfristiger Fix: Core-Update auf eine TYPO3-Version, in der dieser Fehler behoben wurde (prüfen Sie changelog.typo3.org nach dem spezifischen Issue in cgl/VerifiedHostHeader oder NormalizedParamsAttribute).
3. Betroffene TYPO3 Extension¶
TYPO3 Core (typo3/cms-core) – betroffene Dateien:
vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.phpvendor/typo3/cms-core/Classes/Middleware/NormalizedParamsAttribute.php
Keine Dritterweiterung (Extension) ist direkt betroffen. Der Fehler liegt im Core-Middleware-Stack. Allerdings kann eine benutzerdefinierte Extension (z. B. eine Custom-Site-Handling-Erweiterung, die den Request manipuliert oder eigene Middleware einfügt) das Problem indirekt auslösen, indem sie den Host-Header oder die Request-Attribute vor der Core-Verarbeitung verändert.
4. Confidence¶
Confidence: 80%
Begründung: Die Analyse stützt sich auf den klaren Stack-Trace durch die TYPO3 Core-Middleware (VerifyHostHeader → NormalizedParamsAttribute), die spezifische Fehlermeldung über nicht-positive Integer-Offsets (typisch für Array-Zugriff mit fehlerhaften Schlüsseln aus Regex-Ergebnissen), und das Fehlen von Custom-Extension-Code im Stack-Trace. Die trustedHostsPattern-Fehlkonfiguration ist der häufigste Auslöser dieses spezifischen Fehlers in TYPO3 v12/v13. Die 20% Unsicherheit entsteht durch die Möglichkeit eines spezifischeren Core-Bugs in der verwendeten TYPO3-Version, der eine andere genaue Zeilenursache haben könnte.
Nichts anzuzeigen