www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/0b783349-c972-4e89-a6a1-982e0e233e9c/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

ErrorException: Warning: Trying to access array offset on false

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers: "Trying to access array offset on false"¶

1. Ursache identifizieren¶

Der Fehler ErrorException: Warning: Trying to access array offset on false tritt auf, wenn PHP versucht, auf ein Array-Element zuzugreifen, aber der zugrundeliegende Wert false ist (z. B. weil eine Funktion wie explode(), json_decode() oder ein Datenbank-Query fehlgeschlagen ist und false zurückgibt).

Konkrete Ursache im Stacktrace:

• Der Fehler entsteht während der Middleware-Verarbeitung in TYPO3, insbesondere in:
  • VerifyHostHeader.php (Zeile 55)
  • NormalizedParamsAttribute.php (Zeile 44)
• Beide Middlewares arbeiten mit HTTP-Headern oder Server-Parametern (z. B. $_SERVER['HTTP_HOST'], $_SERVER['REQUEST_URI']).
• Mögliche Szenarien:
  1. Fehlender oder ungültiger Host-Header (z. B. in CLI-Kontext oder bei falscher Proxy-Konfiguration).
  2. Ungültige $_SERVER-Variablen (z. B. wenn parse_url() auf einen leeren String angewendet wird).
  3. Fehlerhafte Konfiguration (z. B. trustedHostsPattern in LocalConfiguration.php).
  4. Middleware versucht, auf ein nicht existierendes Array-Element zuzugreifen (z. B. $parts = explode(':', $host); $parts[1] bei einem Host ohne Port).

Wahrscheinlichster Auslöser:

• Die Middleware VerifyHostHeader prüft den Host-Header gegen das trustedHostsPattern. Falls der Header fehlt oder nicht passt, wird intern ein Fehler geworfen.
• Alternativ: NormalizedParamsAttribute versucht, die Request-URI zu parsen, scheitert aber (z. B. bei leerer URI oder ungültigem Format).

2. Fix beschreiben (konkret)¶

Lösungsansätze:

A) Host-Header-Problem (VerifyHostHeader.php)¶

1. Prüfen, ob der Host-Header gesetzt ist:

   // In VerifyHostHeader.php (Zeile ~55):
   $host = $request->getHeaderLine('Host');
   if (empty($host)) {
       // Fallback oder Fehlerbehandlung
       throw new \TYPO3\CMS\Core\Exception('Host-Header fehlt', 1518472181);
   }
   

2. trustedHostsPattern anpassen (in LocalConfiguration.php):

   'SYS' => [
       'trustedHostsPattern' => '.*', // Nur für Entwicklung! Besser spezifisch:
       // 'trustedHostsPattern' => '^(example\.com|localhost)$',
   ],
   

3. Proxy-Konfiguration prüfen (falls TYPO3 hinter einem Reverse Proxy läuft):

   'SYS' => [
       'reverseProxyIP' => '127.0.0.1', // IP des Proxys
       'reverseProxyHeaderMultiValue' => 'first', // oder 'last'
   ],
   

B) Request-URI-Problem (NormalizedParamsAttribute.php)¶

1. Prüfen, ob die URI gültig ist:

   // In NormalizedParamsAttribute.php (Zeile ~44):
   $requestUri = $request->getUri()->getPath();
   if (empty($requestUri)) {
       $requestUri = '/'; // Fallback
   }
   

2. parse_url() mit Fehlerbehandlung:

   $uriParts = parse_url($requestUri);
   if ($uriParts === false) {
       $uriParts = ['path' => '/']; // Fallback
   }
   

C) Allgemeiner Fix (Defensives Programmieren)¶

• Vor Array-Zugriffen prüfen, ob der Wert ein Array ist:

  $parts = explode(':', $host);
  if (is_array($parts) && isset($parts[1])) {
      $port = $parts[1];
  }
  

3. Betroffene TYPO3 Extension¶

• Core-Extension: typo3/cms-core
  • Betroffene Dateien:
    • /vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.php
    • /vendor/typo3/cms-core/Classes/Middleware/NormalizedParamsAttribute.php
  • Version: Der Fehler tritt in TYPO3 v9–v11 auf (in v12+ wurde die Middleware-Architektur überarbeitet).

4. Confidence¶

• 90% (hohe Wahrscheinlichkeit, dass der Fehler durch fehlende Host-Header-Prüfung oder ungültige Request-URI ausgelöst wird).
  • Begründung:
    • Der Stacktrace zeigt klar, dass der Fehler in den Middlewares auftritt.
    • Typische Ursachen (fehlender Host-Header, ungültige URI) sind dokumentiert.
    • Die vorgeschlagenen Fixes sind erprobte Lösungen für ähnliche Probleme in TYPO3.

Zusammenfassung der nächsten Schritte¶

1. Debugging:
   • Prüfen, ob der Host-Header im Request vorhanden ist (var_dump($request->getHeaderLine('Host'))).
   • Loggen der $_SERVER-Variablen (error_log(print_r($_SERVER, true))).
2. Konfiguration anpassen:
   • trustedHostsPattern und Proxy-Einstellungen prüfen.
3. Code-Fix:
   • Defensives Programmieren in den betroffenen Middlewares (Null-Checks, Fallbacks).
4. TYPO3-Update:
   • Falls möglich, auf eine neuere TYPO3-Version aktualisieren (v12+ hat robustere Middleware-Handhabung).

Falls der Fehler weiterhin besteht, wäre ein vollständiger Stacktrace mit den genauen Zeilen (z. B. aus var/log/typo3_*.log) hilfreich für eine präzisere Analyse.