Bug #336
offen[Bugsink] DateMalformedStringException: Failed to parse time string (2026*1-01-01) at position 4 (*): Unexpected character
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/a6f00fa7-6860-4d84-8f6c-d4b5fc398889/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
DateMalformedStringException: Failed to parse time string (20261-01-01) at position 4 (): Unexpected character
Automatisch erstellt durch n8n
KI-Analyse:
Hier ist die präzise Analyse des Fehlers:
1. Ursache¶
Der Fehler DateMalformedStringException entsteht, weil der PHP DateTime-Parser versucht, den String 2026*1-01-01 zu interpretieren. Das Zeichen * ist im Standardformat für Datumsangaben (YYYY-MM-DD) nicht erlaubt. Es handelt sich um eine fehlerhafte Eingabe, die wahrscheinlich aus einem Konfigurationswert, einem Query-Parameter oder einem User-Input stammt und nicht vorher bereinigt (sanitized) wurde. Die Anwendung versucht, dieses unsinnige Format als gültiges Datum zu parsen, was zum Absturz führt.
2. Fix (Konkret)¶
Die Lösung muss verhindern, dass ungültige Datumsstrings an den DateTime-Konstruktor gelangen. Da der Fehler in der Kernel-Schicht (cms-core) auftritt, sollte die Fehlerbehandlung dort erfolgen.
Option A: Direkte Fehlerbehandlung im Application-Layer (Empfohlen)
Füge in AbstractApplication.php (oder Application.php) einen Try-Catch-Block ein, bevor der String geparst wird.
// Im AbstractApplication.php (ca. Location: run() oder Application::handle())
try {
// Versuche, den Parameter zu parsen
$parsedDate = new DateTime($request->get('date'));
} catch (DateMalformedStringException $e) {
// Logge den Fehler und setze einen sinnvollen Default oder leite einen Fehler ab
Logger::error("Ungültiges Datum im Request: " . $e->getMessage());
// Beispiel: Setze einen Standardwert oder wirf einen 400 Bad Request
$parsedDate = new DateTime('2026-01-01');
}
Option B: Input Validation im Middleware
Da der Fehler über MiddlewareDispatcher fließt, könnte auch eine Validierung im NormalizedParamsAttribute oder einem eigenen Middleware erfolgen, bevor die Daten an die Anwendung weitergegeben werden.
3. Betroffene TYPO3 Extension¶
cms-core (Typo3 Core)
Alle Stack-Trace-Einträge führen in die Kernkomponenten (/vendor/typo3/cms-core/...). Der Fehler liegt somit in der Standardimplementierung der Typo3-CMS, nicht in einer benutzerdefinierten Extension.
4. Confidence¶
95%
Der Fehlertext ist sehr spezifisch und deutet eindeutig auf eine fehlerhafte Datumsformatierung hin. Die Zuordnung zur cms-core ist durch die vollständige Stack-Trace-Kette eindeutig.
Nichts anzuzeigen