" ' Formular Datenbank Problem

Zak85

Grünschnabel
Habe da seit nem Serverupdate meines Anbieters ein Problem...

Ich habe z.b. ein User der sein Profil updaten will funktioniert einwandfrei oder auch die Registrierung, eigentlich alle Formulare nur hat das ganze einen Hacken!

das ' Zeichen

Jedesmal wenn jemand das Zeichen nutzt etc wird die Datenbank launisch und trägts gar ned erst ein, respektive halt es wird im Code falsch verarbeitet!

Wie bring ich das in Ordnung? Die Eintragung funktioniert ganz normal...

$comment = $HTTP_POST_VARS["comment"];
$member = $HTTP_POST_VARS["member"];

include ("config/dbconnect.php");

$eintrag = "INSERT INTO news_comments (comment, member) VALUES ('$comment'', '$member')";

$eintragen = mysql_query($eintrag);


danke für die mühe, sollte das problem schon mal behandelt worden sein, tuts mir leid, war vorher auf der suche im forum wie ein gestöhrter :D aber fand nix, respektive keine lösung
 
Dieser Thread sollte Dir weiterhelfen. Im Gegensatz zu einem einfachen [phpf]addslashes[/phpf] werden dort Lösungen besprochen, durch die das Skript auch bei dem nächsten Provider noch funktioniert.

Übrigens ist $HTTP_POST_VARS veraltet und wurde durch $_POST ersetzt.

Gruß hpvw
 
was ihr mir da gesagt hat, funktionierte wirklich.. jetzt habe ich aber nur ein Problem...
bein nem textfeld z.b. bekomm ich dann mit stripslashes(nl2br($text)); anstatt ein abstand ein <br /> ...

wie beheb ich so n problem?

zur info: alle felder die ich eintrage erhalten addslashes() in die datebank und alle ausgaben halt mit stripslashes()

oder wird nl2br nich mehr benötigt?
 
bein nem textfeld z.b. bekomm ich dann mit stripslashes(nl2br($text)); anstatt ein abstand ein <br /> ...
Von welchem Abstand ist die Rede?

Die addslashes()-Funktion wird im Zusammenhang mit einer Datenbankabfrage (meist) nur dazu gebraucht, um eine Zeichenkette mit etwaigen Anführungszeichen (sowohl U+0022 als auch U+0027) und dem umgekehrte Schrägstrich (U+005C) zu „entschärfen“, um die Zeichenkette bei der Deklaration der Datenbankabfrage nicht vorzeitig zu beenden oder die Entmarkierung aufzuheben. In der Datenbank selbst sind diese Fluchtzeichen allerdings nicht mehr existent. Daher ist auch das anschließende Entfernen dieser nicht existenten Fluchtzeichen durch stripslashes() überflüssig – es sei denn, PHP „entschärft“ bereits automatisch die GPC-Variablen durch Fluchtzeichen (siehe magic_quotes_gpc-Konfigurationseinstellung).
 
Die Funktion nl2br(); wandelt \n in <br /> um! Da in einer Textarea aber \n für Zeilenumbrüche verwendet wird, würde ich diese Funktion nicht bei Text anwenden, welcher in eine Textarea eingefügt wird.
 
@German
Seit wann ist denn ein \n eine Sicherheitslücke? ;)

Zudem hat nero_85 vollkommen Recht. Wenn du Daten per <textarea> annimmst, steht für jedesmal wenn der User Return drückt ein \n drin. Verwende ich jetzt den übergebenen Text im normalen HTML-Kontext (z.B. anzeigen von Beiträgen in einem Gästebuch), so wird \n nicht wieder zu einem entsprechenden Absatz wie der Nutzer das wünscht, da die Formatierung des HTMLs die Anzeige des HTMLs nicht beinflusst. Folglich muss man aus einem \n ein <br/> machen, um auch in der HTML Seite einen Absatz anzuzeigen. Problem ist jetzt natürlich, wenn ich bei der Eingabe alle \n durch <br/> ersetze und in die Datenbank schreibe, gibt es Probleme sobald es sich um ein System handelt, bei dem nachträglich die Einträge geändert werden können (z.B. Forum). Weil jetzt würde ja wieder die Seite mit dem Textarea geladen werden und das Textarea würde dann mit den Daten aus der Datenbank gefüttert werden. Dort würden dann immer wieder <br/> anstatt dem gewünschten \n welches einen Absatz im Textarea erzeugt, welche dann auch im Textarea als plain text angezeigt werden, was natürlich nicht gewünscht ist.

Jetzt muss man sich entscheiden, entweder die \n in der Datenbank speichern und bei jedem Anzeigen der Seite nl2br ausführen, oder die <br/> in der Datenbank speichern dafür dann aber jedesmal bei editieren aus jedem <br/> ein \n für das Textarea machen. Je nachdem, welche Operation öfter vorkommt, entscheidet mansich dann für die eine oder andere Lösung.
 
GH@NDI hat gesagt.:
@German
Seit wann ist denn ein \n eine Sicherheitslücke? ;)
\n nicht, aber addslashes() weglassen, siehe Link ;)
Zudem hat nero_85 vollkommen Recht.
Dann schon eher Gumbo, obwohl mein Code-Fetzen auch funktioniert, man beachte das "wenn überhaupt".
Wenn du Daten per <textarea> annimmst, ...

Jetzt muss man sich entscheiden, ....
Langer Rede kurzer Sinn:
Üblicherweise schreibt man in eine DB Rohdaten und formatiert sie bei der Ausgabe.
 
Zurück