Tech 16. May. 2011

TYPO3: RealURL und nicht valide Lookup-Ergebnisse (nomatch bei postVarSets mit lookUpTable)

Wenn man per RealURL bestimmte Parameter bzw. Datenbank-IDs kodiert, kann man wunderhübsche URLs erzeugen. I.d.R. macht man das für Datenbank-Records mit “postVarSets” über eine “lookUpTable”.

Standardmäßig werden so aber alle Werte angenommen und als gültig verarbeitet - was in der Realität aber vollkommen falsch ist. Wird eine URL mit einem Alias aufgerufen, welches anhand der lookup-Konfiguration nicht gefunden werden kann, erwarte ich eine Fehlermeldung. Am besten einen 404-Fehler, welcher über das TYPO3 Handling abgearbeitet wird.

Hierfür muss man aber selbst Hand anlegen.

1:

In der RealURL Konfiguration muss das Fehlerhandling aktiviert werden:

['lookUpTable']['enable404forInvalidAlias'] = 1

Dann sollte man prüfen, ob die angewandte Where-Clause ggf. erweitert werden muss, z.B. um ungültige Records heraus zu filtern:

['lookUpTable']['addWhereClause'] = " AND hidden!=1 AND delete!=1 AND iminternenreview=!1"

2:

An sich sollte das reichen, aber in RealURL sind ein paar Dinge eigenartig bzw. buggy implementiert.

In der Funktion “lookUpTranslation” wird in der letzten Zeile, wenn kein Mapping möglich war, der Eingabewert zurück gegeben. Im Kommentar steht hier bereits, dass das komisch ist. Wenn man die ID als Pfadsegment mappt und kein anderes Feld, führt das dann sogar zu fehlern, weil später nicht unterschieden werden kann, ob der Wert beim Lookup gefunden wurde (return Wert der ID) oder kein Wert gefunden wurde (return Wert ist auch eine ID). Hier muss sauberer Weise ein “return null” rein.

In der Funktion “decodeSpURL_getSequence” im Bereich “elseif (is_array($setup[‘lookUpTable’])” wird dann letztlich bewertet, ob der Wert gültig ist oder ein Redirect erfolgen soll. Die Abfrage

"if ($setup['lookUpTable']['enable404forInvalidAlias'] && !t3lib_div::testInt($value) && !strcmp($value, $temp))"
ist dabei aber etwas unsauber. Hier erfolgt nur ein Redirect, wenn Ein-und Ausgabewert gleich sind (siehe oben) und der Wert kein Integer ist. Die testInt-Anweisung kann gleich entfallen oder mit mi OR (“   ”) angegeben werden. Und das

“strcmp” ist entsprechen der oben stehenden Erläuterung etwas wage. An sich muss nicht EIngabe=Ausgabe geprüft werden, sondern Lookup erfolgreich/nicht erfolgreich. Also im Ergebnis:

if ($setup['lookUpTable']['enable404forInvalidAlias'] && !$value)

Und schwupp, schon erfolgt ein Redirect, wenn nicht gültige Werte in der URL an die Website übergeben werden.