Archiv

TechInfo

Klasse Fehler in den Datenquellen

By Dirk Bergles

Es gibt einfach Fehler mit Stil, die "Spass" machen.

Es begann mit einem Fehlverhalten von Datenquellen, sobald diese auf Kategorien mit ( ) trafen.

Diese Klammern wurden HTML safe codiert, da sie als Parameter übergeben werden.
z.B. die Kategorie DE\Allgemein (Test) endet als Parameter r0=DE%5CAllgemein%20&#40Test&#41
Weil irgendwann mal irgendwer das CrossSiteScripting bis aufs Messer verfolgt und ausgebrannt hat. So wurden dann rigeros einfach alle Parameter "sicher" gemacht, damit sie, sofern im HTML landen, keinen Unfug anrichten können.
Nun wird diese Kategorie dummerweise auch intern benutz, zum Vergleich und zur Suche von Kategorien. Der Wert wird zwar URLDecodiert, aber nicht HTML unsicher gemacht, damit verbleiben die bösen Klammern als Codes im String und jeglicher Vergleich schlägt fehl.
Dies ist nun geändert, so daß die Kategorie nicht mehr als HTML safe ausgelesen wird. Sollte sie nun irgendwo im HTML Code enden; das kann leicht per RTags geschehen, dann muß einfach der schlaue WebMaster oder Entwickler daran denken.
Geändert wurde der Aufruf zum Auslesen der Kategorie. Bisher über getParam() der URL Klasse. Nun einfach getParamUnsafe()

Das war dann aber noch nicht alles...
Denn beim Testen einer bestimmten Datenquelle fiel auf, dass sie in der Demo-Version ansonsten funktionierte, aber in der Dev-DB leider nicht.

Es hing mit den \\ zusammen die ebenfalls automatisch berechnet wurden.
Zunächst wurde für jedenKategorie-Eintrag korrekt ein Parameter berechnet, der zum Aufklappen genutzt werden konnte.
Ungefähr so: root\DE\Allgemein
Dann wurde der noch URLEncodiert, damit er als Parameter in der URL genutzt werden konnte und ausserdem wurden zuvor \ durch \\ ersetzt, damit dieses ReplacementTag in einer Formel eingesetzt werden konnte. Denn dort wird es ja als reine Textersetzung eingesetzt, so dass sich ein \ als Escape Zeichen selber aushebelt. Letztendlich landen also die \\ als \ im Parameter, da sie in der Formel escaped werden.
Fertig.
Früher, also vor 7.70 0, erfolgte das URLEncodieren über ein Evaluate und @URLEncode.
Dann kam eine schlaue Routine daher, welche das alles ohne Evaluate schaffen sollte.
Unterschied. @URLEncode kodiert keine \
Damit blieb das \ erhalten und konnte, weil es ein \\ wurde, in der Formel korrekt genutzt werden.

Die neue Routine kodiert sehrwohl \ in %5C.
Also, da ja zuvor ersetzt, landen %5C%5C in der Formel. Da escaped sich aber nix, also bleiben beide Zeichen erhalten und landen so als %5C%5C im Parameter, werden beim Abschicken wieder Decodiert und die Datenquelle sucht wie blöde nach \\
Bzw. noch viel schlimmer. Bei der Kategoriesuche wird der Pfad aufgesplittet und es entstehen leere Kategorien zwischen den Kategorien.

Die Lösung ist nun, dass das Ersetzen, \ in \\, nicht mehr durchgeführt wird, weil es unnötig ist, sofern der String sowieso komplett codiert wird. Sollte also die @URLDecode Methode nochmal zum Einsatz kommen, dann hoffe ich sehr, dass mich jemand daran erinnert zusätzlich die Ersetzung \ nach %5C einzubauen.

Das hat eigentlich nichts mit dem CrossSiteScripting zu tun, war aber nicht weniger spannend....

Einen Kommentar erstellen