www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/7a12a953-47fe-4f32-893e-004716c2bfd8/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

ErrorException: Warning: Trying to access array offset on null

Automatisch erstellt durch n8n

KI-Analyse:

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

1. Ursache identifizieren¶

Der Fehler ErrorException: Warning: Trying to access array offset on null tritt auf, wenn versucht wird, auf ein Array-Element zuzugreifen, das auf null zeigt (z. B. $array['key'], wobei $array selbst null ist).

Konkrete Ursache im Stacktrace:

• Der Fehler entsteht in der Middleware-Kette von TYPO3, genauer in:
  • /vendor/typo3/cms-core/Classes/Middleware/NormalizedParamsAttribute.php:44
    (oder eine der vorherigen Middlewares wie VerifyHostHeader).
• Hypothese:
  Eine der Middlewares (wahrscheinlich NormalizedParamsAttribute) versucht, auf ein Server- oder Request-Array ($_SERVER, $_GET, $_POST oder ein PSR-7-Request-Objekt) zuzugreifen, das nicht initialisiert oder null ist.
  Typische Szenarien:
  • Fehlende Server-Variablen (z. B. HTTP_HOST, REQUEST_URI).
  • Falsche Konfiguration (z. B. fehlende .htaccess-Regeln oder falsche Proxy-Einstellungen).
  • Manipulierte Requests (z. B. leere Host-Header oder fehlende X-Forwarded-*-Header bei Reverse Proxies).
  • TYPO3-Konfiguration (z. B. falsche trustedHostsPattern oder reverseProxy-Einstellungen).

Beispiel-Code (aus NormalizedParamsAttribute.php):

// Möglicher Auslöser (vereinfacht):
$host = $request->getServerParams()['HTTP_HOST']; // <- $request->getServerParams() ist null!

Falls $request->getServerParams() nicht korrekt initialisiert ist, führt der Zugriff auf ['HTTP_HOST'] zum Fehler.

2. Fix beschreiben (konkret)¶

Mögliche Lösungen:

A) Server-Konfiguration prüfen (häufigste Ursache)¶

• Apache/Nginx:
  • Stelle sicher, dass alle erforderlichen Server-Variablen (HTTP_HOST, REQUEST_URI, SCRIPT_NAME, etc.) gesetzt sind.
  • Bei Reverse Proxies (z. B. Cloudflare, Load Balancer):
    • TYPO3 muss die originalen Request-Header erhalten (z. B. X-Forwarded-Host, X-Forwarded-Proto).
    • Beispiel für .htaccess (Apache):

      RewriteEngine On
      RewriteCond %{HTTP:X-Forwarded-Proto} !https
      RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]
      

    • In typo3conf/LocalConfiguration.php:

      'reverseProxy' => true,
      'reverseProxyIP' => '127.0.0.1', // IP des Proxys
      'reverseProxyHeaderMultiValue' => 'first', // oder 'last'
      

B) TYPO3-Konfiguration anpassen¶

• trustedHostsPattern prüfen (in typo3conf/LocalConfiguration.php):

  'SYS' => [
      'trustedHostsPattern' => '.*', // Nur für Entwicklung! Besser: spezifisches Pattern
  ],
  

  • Empfehlung: Verwende ein spezifisches Pattern (z. B. ^(www\.)?meine-domain\.de$).

C) Middleware-Code patchen (falls nötig)¶

• Temporärer Workaround (nur für Debugging!):
  In NormalizedParamsAttribute.php (oder der betroffenen Middleware) eine Null-Prüfung einbauen:

  $serverParams = $request->getServerParams() ?? [];
  $host = $serverParams['HTTP_HOST'] ?? 'default-host.local';
  

  • Achtung: Dies ist keine dauerhafte Lösung, sondern nur zur Fehlerlokalisierung!

D) Request-Objekt debuggen¶

• Logge den Request vor dem Fehler:

  \TYPO3\CMS\Core\Utility\GeneralUtility::devLog(
      'Server Params: ' . print_r($request->getServerParams(), true),
      'my_extension',
      3 // Severity: 3 = ERROR
  );
  

  • Prüfe, ob $_SERVER oder das PSR-7-Request-Objekt leere Werte enthält.

3. Betroffene TYPO3 Extension¶

• Core-Extension: typo3/cms-core (insbesondere die Middleware NormalizedParamsAttribute).
• Mögliche Drittanbieter-Extensions:
  • Falls eine Custom Middleware im Spiel ist, könnte diese den Request manipulieren.
  • Extensions, die Server-Variablen auslesen (z. B. für SEO, Security oder Routing).

4. Confidence (0-100%)¶

• 90% – Die Ursache liegt mit hoher Wahrscheinlichkeit in:
  • Fehlenden Server-Variablen (z. B. HTTP_HOST nicht gesetzt).
  • Falscher Proxy-Konfiguration (Reverse Proxy nicht korrekt eingerichtet).
  • TYPO3-Konfiguration (trustedHostsPattern, reverseProxy).
• 10% Restunsicherheit:
  • Falls der Fehler nur in bestimmten Umgebungen auftritt (z. B. Docker, Kubernetes), könnte ein Race Condition oder ein Caching-Problem vorliegen.

Zusammenfassung der nächsten Schritte¶

1. Server-Variablen prüfen:
   • Führe phpinfo() aus oder logge $_SERVER in index.php.
   • Stelle sicher, dass HTTP_HOST, REQUEST_URI und SCRIPT_NAME gesetzt sind.
2. TYPO3-Konfiguration anpassen:
   • reverseProxy und trustedHostsPattern korrigieren.
3. Request debuggen:
   • Logge das PSR-7-Request-Objekt vor dem Fehler.
4. Middleware-Code temporär patchen (nur für Debugging!).
5. Proxy-Einstellungen prüfen (falls verwendet).

Falls der Fehler weiterhin besteht, wäre ein vollständiger Stacktrace mit Variablenwerten hilfreich.