RegExp "Date" lässt fehlerhafte Werte zu

ghost commented 13 years ago

Ich bin gerade über einen Fehler gestolpert. Wenn ich die Prüfung eines Formularfeldes auf "Datum" stelle, kann der User folgendes eingeben:

```,,,,10.10.2006,,,,```

Das wird als gültiges Datum gewertet.

--- Originally created by matze on November 16th, 2009, at 03:41pm (ID 1163)

leofeyer commented 13 years ago

Ich kann den Fehler weder in der Onlinedemo noch in meiner lokalen Umgebung reproduzieren.

--- Originally created on November 16th, 2009, at 03:44pm

ghost commented 13 years ago

Das ist ja komisch. Auf dem Server der Seite, die ich gerade erstelle, tritt der Fehler nämlich auf: http://dev.photovoltaikversicherung.biz/meldungen/schaden.html Einfach unter "Schadentag" mal den Wert von oben eintragen.

Ich habe dort die Version 2.7.5 von TL laufen.

--- Originally created by matze on November 16th, 2009, at 03:48pm

ghost commented 13 years ago

Also ich kann den Fehler auch auf anderen Installationen von mir reproduzieren. Es gibt auch einen Forumseintrag von mir dazu: http://www.typolight-community.de/showthread.php?p=25602#post25602

--- Originally created by matze on November 17th, 2009, at 09:01pm

ghost commented 13 years ago

Auch bei mir tritt das Verhalten auf (Hoster cyon.ch). Willst du einen Testzugang?

--- Originally created by Sebastian on November 20th, 2009, at 05:30pm

ghost commented 13 years ago

HI

ups, habe mich im Hoster geirrt. Es ist die ETES GmbH, nicht Cyon. Entschuldigung.

Sebastian

--- Originally created by Sebastian on November 20th, 2009, at 05:39pm

ghost commented 13 years ago

Ich hab zwar noch nicht herausgefunden warum es ueberhaupt funktionieren konnte, aber die regex in Widget.php scheinen mir nicht korrekt. preg_match und preg_match_all suchen in einem String nach passenden Teilstrings. Bei einem Datum wollen wir jedoch einen exact match haben, dies wurde jedoch uebersehen.

Aenderungen in system/libraries/Widget.php:

//Zeile: 540
//  if (

![](preg_match('~'. $objDate->getRegexp($GLOBALS['TL_CONFIG']['dateFormat']) .'~i', $varInput))
    if ()preg_match('~^'. $objDate->getRegexp($GLOBALS['TL_CONFIG']['dateFormat']) .'$~i', $varInput))

//Zeile: 549
//  if (

![](preg_match('~'. $objDate->getRegexp($GLOBALS['TL_CONFIG']['timeFormat']) .'~i', $varInput))
    if ()preg_match('~^'. $objDate->getRegexp($GLOBALS['TL_CONFIG']['timeFormat']) .'$~i', $varInput))

//Zeile: 558
//  if (

![](preg_match('~'. $objDate->getRegexp($GLOBALS['TL_CONFIG']['datimFormat']) .'~i', $varInput))
    if ()preg_match('~^'. $objDate->getRegexp($GLOBALS['TL_CONFIG']['datimFormat']) .'$~i', $varInput))

Mit diesen Anpassungen wird immer der komplette String gematched (oder eben auch nicht) und es wird das korrekte Ergebnis zurueckgegeben. Alle anderen relevanten rgxp beinhalten bereits ^und $ und sollten somit passen. Bitte testen ob meine Changes so passen.

--- Originally created by xtra on November 21st, 2009, at 01:55am

ghost commented 13 years ago

Nachtrag: Im Backend tritt das Problem nicht auf, da dort die Eingabewerte "gecleaned" werden und nur der match dann abgespeichert wird.

Nach meinen obigen Aenderungen ist man somit auch im Backend gezwungen einen sinnvollen Wert einzugeben, was meiner Meinung nach auch richtig ist, ansonsten laesst man der pregmatch zuviel Freiraum wie z.B. das Parsen von Werten wie ".....```...--fffgfgf10.10.1999.sdkjkldcvkf12.10.1970fgghikjdfkj" Hier sind nun 2 Daten enthalten (von welchen bislang das erste genommen werden sollte) doch dies erschliesst sich vermutlich nur uns Programmierern und nicht dem Endanwender.

Wir koennten jedoch auch alternativ den Widget Wert abschliessend auf das Match setzen (Array: optionaler Parameter #3, index 0), was jedoch gegebenenfalls Nebeneffekte nach sich ziehen koennte, da die Validierung eben eine Validierung ist und kein "zurechtstutzen bis es passt". :)

--- Originally created by xtra on November 21st, 2009, at 02:20am

leofeyer commented 13 years ago

--- Originally completed on November 21st, 2009, at 12:44pm

contao / core

RegExp "Date" lässt fehlerhafte Werte zu #1163