CONTENIDO Forum

Hallo,
ich habe folgende Beobachtung gemacht:
Ein mit einer der setProperty-Funktionen gespeicherter Wert enthält, wenn man ihn mit einer der getProperty-Funktionen wieder abruft, mehr Slashes als vorher.

Ich habe noch nicht in den Quelltext geschaut, aber ein bisschen systematisch ausprobiert:
Offenbar wenden die setProperty-Funktionen vor dem Speichern in der Datenbank ein 'addslashes' auf die Strings an, was ja auch vernünftig ist.
Offenbar entfernen die getProperty-Funktionen die Slashes beim Zurücklesen aber nicht mit einem 'stripslashes' wieder, wie es nötig wäre.

Natürlich kann man das in den Modulen nachholen, ich denke aber trotzdem, dass es eher ein Bug ist als ein Feature und in der nächsten Version korrigiert werden sollte.

das etwas seltsame verhalten kann ich bestätigen... somit verschoben...

da muss timo was dazu sagen, wenn er wieder mal zeit hat ist ja eine genericdb sache...

@Stefan_Br
ändere mal in der classes/class.genericdb.php auf vielleicht hilfts ja...

Es sei erwähnt - was hier aber vielleicht gar nicht zutrifft -, dass Texte, die via Formular abgesendet und dann in der DB mit setIrgendwas gespeichert werden, vor dem Speichern mit stripslashes behandelt werden müssen...

Gruß
HerrB

@HerrB:
Das ist eine Methode, aber nicht die vorzuziehende:
Dadurch gehen nämlich die Slashes für immer verloren und das kann je nach Anwendungsfall fatal sein. (Ich zum Beispiel speichere auf diese Weise Code-Schnipsel).
Besser ist es, wie man es auch irgendwo bei php.net nachlesen kann:
Vor dem Speichern ein addslashes, damit nicht irgendwelche böse Zeichen Code oder Datenbank verwirren, nach dem Abrufen stripslashes, um die von addslashes hinzugefügten Slashes wieder zu entfernen.
- So kann man auf sichere weise speichern, was man will, und bekommt es garantiert so wieder zurück, wie man es gespeichert hat.

@emergence:
Ne ne, wie ich sehe müsste die Reihenfolge schon passen - man muss die Dinge ja in umgekehrter Reihenfolge beim Zurückholen anwenden wie beim Wegspeichern. Allerdings ist mir nicht ganz klar, wozu überhaupt die übrigen Umwandlungen vorgenommen werden: Sie werden ja eh wieder rückgängig gemacht, also können sie ja nur dazu dienen, dass nicht irgendwelche Slashes oder Hochkommata die SQL-Syntax zerstören und genau dafür sind ja eigentlich addslashes / stripslashes gedacht und müssten entsprechend ausreichen. Die anderen Filter dürften allerdings auch nicht stören.

Ich glaube aber, dass der Fehler in einer ganz anderen Datei liegen muss: die von dir angesprochene datei ist doch die Datenbankabstraktion; also müsste das Problem ja immer dann auftauchen, wenn was in die Datenbank geschrieben wird. Dies ist aber offenbar nicht der Fall - ansonsten müsste man ja z.B. beim Speichern bzw. Abrufen des Modulcodes das Gleiche erleben und das würde ja wiederum bedeuten, dass das ganze Contenido unbrauchbar sein müsste.

Andrerseits kommt mir auf die Schnelle, wenn ich den Code vom Funktionsaufruf ab mal so verfolge, auch nichts anderes schuldig vor. Ich wüsste aber auch nicht wo der Fehler liegt.
Aber es ist doch so, dass ganz Contenido diese Strukturen benutzt, oder?

Jein, eigentlich erhält jeder String zusätzlich (aufgrund des magic_quotes bzw. der Emulation) zusätzliche Slashes, die halt dann einmal wieder rausgenommen werden müssen - da geht Dir (auch bei Code) nix verloren...

Gruß
HerrB

Asche auf mein Haupt!

Hatte vergessen, dass Contenido ja mit magic_quotes_gpc läuft und entsprechend falsch getestet. Dann besteht das Problem ja gar nicht!!
Am besten also den ganzen Thread hier löschen!!

Entschuldigung

hmm...

ich hab mir das letzte mal nach den code noch etwas durch gesehen...
es stimmt das der entwickler selbst dafür sorgen muss, das werte die via post abgesetzt werden via stripslashes vorbehandelt werden müssen...

also löschen möcht ich den thread eigentlich nicht... ich verschieb es nach misc 4.6.x