[PHP] Textarea wordt niet opgeslagen in database

[Verwijderd]

Dag Tweakers,

Eerst en vooral heb ik zelf al op internet en in de FAQ gezocht naar een oplossing, maar niet gevonden.

De situatie:
Ik heb een html formulier met meerdere inputvelden, paar selectboxes, paar text input velden en een textarea.
Bij submitten van het formulier ga je naar "verwerken.php" waar de waarden opgehaald worden via de POST container en in de database worden opgeslagen.
Bij alle veldjes lukt dit prima, behalve de textarea, daar wordt niets van opgeslagen in de databank...

Het gaat niet om een verkeerd getypye variabelenaam of iets in die aard.

Ik heb meerdere instellingen geprobeerd in de mysql database. Op dit moment staat het ingesteld als een VARCHAR met een limit van 1000. Ook TEXT en consoorten al geprobeerd, zonder zichtbaar resultaat.

Pagina 1
<textarea name="advertentieTekst" id="advertentieTekst" cols="45" rows="9" class="contactinput"></textarea>

Pagina 2
$advertentieTekst=$_POST["advertentieTekst"];

Mysql pagina 2
mysql_query("INSERT INTO advertentie (blaat, advertentie_tekst)
VALUES ('$blaat', '$advertentieTekst')")


Iemand enig idee? Ik ben namelijk ten einde raad...

[RetroTycoon]

Op sql-injectie na, wat geeft een echo() op die waarde. Eigenlijk simpel debuggen, maar ik help je even

[_Sunnyboy_]

Heb je al geprobeerd op pagina 2 $_POST["advertentieTekst"]; te echo'en? Dan kan je in ieder geval isoleren waar je fout zit.

Als bovenstaande code echt de code is die je gebruikt is het echter maar beter dat het niet werkt, want je zet de deur wagenwijd open voor SQL-injection...

Edit: Two minds, same answer

[ Voor 5% gewijzigd door _Sunnyboy_ op 23-07-2009 21:33 ]

[Cascade]

Paar dingen:
- staat er wel een method="post" in je form?
- dump de inhoud van je geposte vars en de hele $_POST eens (var_dump, print_r, je kent het).
- regel de escaping van je vars in de query.
- controleer of mysql_query een TRUE of FALSE terug geeft.
- kijk eens wat mysql_error en mysql_errno zeggen.

Standaard debuggen.

_{* spuit (half) 11}

[ Voor 4% gewijzigd door Cascade op 23-07-2009 21:35 ]

[Verwijderd]

Ik ben geen ervaren programmeur, maar dat hadden jullie ondertussen dus gemerkt ...

De variabele wordt wel ge-echod op pagina 2, het gaat dus fout bij het opslaan in de database.
Geen mysql errors, de andere veldjes worden wel prima opgeslagen (via dezelfde query).
Method POST staat er inderdaad wel in.

Ik gok dus dat het inderdaad iets met die "escaping" te maken heeft...

[Gersomvg]

Zover ik weet kan je van:

INSERT INTO advertentie (blaat, advertentie_tekst) VALUES ('$blaat', '$advertentieTekst')

gewoon

INSERT INTO advertentie VALUES ('$blaat', '$advertentieTekst')

maken, toch?

[ Voor 10% gewijzigd door Gersomvg op 23-07-2009 21:47 ]

[RobIII]

Gersompie schreef op donderdag 23 juli 2009 @ 21:45:
Zover ik weet kan je van:

INSERT INTO advertentie (blaat, advertentie_tekst) VALUES ('$blaat', '$advertentieTekst')

gewoon

INSERT INTO advertentie VALUES ('$blaat', '$advertentieTekst')

maken, toch?

Behalve dat 't nog steeds gevoelig is voor SQL injection heb je nu ook nog eens klaargespeeld dat je maar moet hopen dat de juiste values in de juiste fields komen. Nee, dan kun je beter expliciet de velden even noemen.

[ Voor 6% gewijzigd door RobIII op 23-07-2009 21:49 ]

[Verwijderd]

Gersompie schreef op donderdag 23 juli 2009 @ 21:45:
Zover ik weet kan je van:

mysql_query("INSERT INTO advertentie (blaat, advertentie_tekst) VALUES ('$blaat', '$advertentieTekst')")

gewoon

mysql_query("INSERT INTO advertentie VALUES ('$blaat', '$advertentieTekst')")

maken, toch?

Klopt, maar er zijn nog meer veldjes, $blaat is maar een dummy variabele die ik hier plaats als voorbeeld.
Mijn veldjes worden niet in dezelfde volgorde opgeslagen als ze in de database moeten komen, vandaar deze iets langere manier.

Ondertussen wat zoekwerk verricht naar mysql injection en daar kom ik zelf wel uit om dat op te lossen.
Bedankt voor de tip iedereen.

Ik heb gemerkt dat het probleem zich pas voordoet vanaf dat er een spatie in de textarea zit, 1 lange string tekst lukt blijkbaar wel...

[PeterSelie]

Gersompie schreef op donderdag 23 juli 2009 @ 21:45:
Zover ik weet kan je van:

INSERT INTO advertentie (blaat, advertentie_tekst) VALUES ('$blaat', '$advertentieTekst')

gewoon

INSERT INTO advertentie VALUES ('$blaat', '$advertentieTekst')

maken, toch?

Nee, dat kan waarschijnlijk niet. Je wilt alleen in de velden blaat en advertentie_tekst wat plaatsen. In het geval dat er ook een 'ID' veld in de tabel terug te vinden is wil je daar waarschijnlijk niets in plaatsen (auto increment). Op deze manier zal je dus alle row srespectievelijk tot de in te voegen waarden moeten noemen bij naam.

[RobIII]

Verwijderd schreef op donderdag 23 juli 2009 @ 21:49:
Mijn veldjes worden niet in dezelfde volgorde opgeslagen als ze in de database moeten komen, vandaar deze iets langere manier.

En betere manier. Je kunt beter wat teveel typen dan te weinig Leer jezelf dus vooral aan expliciet te zijn in je opdrachten; ga nooit van impliciete zaken uit (...tenzij je hééééél zeker weet dat 't kan)

Verwijderd schreef op donderdag 23 juli 2009 @ 21:49:
Ondertussen wat zoekwerk verricht naar mysql injection en daar kom ik zelf wel uit om dat op te lossen.

Verwijderd schreef op donderdag 23 juli 2009 @ 21:49:
Ik heb gemerkt dat het probleem zich pas voordoet vanaf dat er een spatie in de textarea zit, 1 lange string tekst lukt blijkbaar wel...

Omdat je een string tussen quotes moet zetten -> Even lezen/kijken/zoeken. Dat MySQL het überhaupt vreet als er geen spaties in staan is dan weer bout van MySQL

[ Voor 42% gewijzigd door RobIII op 23-07-2009 21:53 ]

[Gersomvg]

SoaDmaggot schreef op donderdag 23 juli 2009 @ 21:50:
[...]

Nee, dat kan waarschijnlijk niet. Je wilt alleen in de velden blaat en advertentie_tekst wat plaatsen. In het geval dat er ook een 'ID' veld in de tabel terug te vinden is wil je daar waarschijnlijk niets in plaatsen (auto increment). Op deze manier zal je dus alle row srespectievelijk tot de in te voegen waarden moeten noemen bij naam.

Lool.. dan doe ik gewoon omslachtig Ik doe namelijk altijd VALUES( '', '', '$variabele', '' '')
Hier de sql-injectie-vrije manier:

mysql_query("INSERT INTO advertentie (blaat, advertentie_tekst) VALUES ('".addslashes($blaat)."', '".addslashes($advertentieTekst)."')")

[ Voor 3% gewijzigd door Gersomvg op 23-07-2009 21:54 ]

[Verwijderd]

Nou nog even goed leren escapen met mysql_real_escape_string, en je bent er bijna. Het enige wat dan nog ontbreekt is een goede wrapper, want de mysql_* functies direct vanuit een applicatie aanroepen is nog steeds gepruts.

[hostname]

Gersompie schreef op donderdag 23 juli 2009 @ 21:53:
[...]

Lool.. dan doe ik gewoon omslachtig Ik doe namelijk altijd VALUES( '', '', '$variabele', '' '')
Hier de sql-injectie-vrije manier:

mysql_query("INSERT INTO advertentie (blaat, advertentie_tekst) VALUES ('".addslashes($blaat)."', '".addslashes($advertentieTekst)."')")

Voor het escapen wil je msyql_real_escape_string gebruiken, geen addslashes.

[Xander]

RobIII schreef op donderdag 23 juli 2009 @ 21:50:
[...]

Omdat je een string tussen quotes moet zetten -> Even lezen/kijken/zoeken. Dat MySQL het überhaupt vreet als er geen spaties in staan is dan weer bout van MySQL

Hij escaped de vars nu weliswaar niet, maar ze staan toch wel tussen quotes...? Zie zo snel niet waarom het met een spatie nu fout zou moeten gaan... (met quotes of slashes wordt het een ander verhaal)

[RobIII]

Xander schreef op donderdag 23 juli 2009 @ 21:59:
[...]


Hij escaped de vars nu weliswaar niet, maar ze staan toch wel tussen quotes...?

Ik zou zweren dat ze er straks niet stonden

[Verwijderd]

@allen hierboven

Via de mysql_real_escape_string functie om sql injectie tegen te gaan is blijkbaar ook mijn probleem met de textarea opgelost.

Allen bedankt voor de tips (was me niet bewust van dit gevaar... ).

De oplossing leek misschien voor de hand liggend, maar als je niet weet waar de fout zit, kan je wel even zoeken....

[Gersomvg]

hostname schreef op donderdag 23 juli 2009 @ 21:56:
[...]

Voor het escapen wil je msyql_real_escape_string gebruiken, geen addslashes.

Ulp Waar heb ik dat nou weer verkeerd aangeleerd..
Sowieso voel ik me ontzettend noob ineens (heb toch al wel een paar jaar php ervaring) aangezien er werkelijk in elke 20 tekens PHP die ik hier post wel fouten zitten

edit: Ben gelukkig niet 100% dom Er is iig een discussie over geweest http://shiflett.org/blog/...-mysql-real-escape-string

[ Voor 15% gewijzigd door Gersomvg op 23-07-2009 22:29 ]

[RobIII]

Gersompie schreef op donderdag 23 juli 2009 @ 22:09:

edit: Ben gelukkig niet 100% dom Er is iig een discussie over geweest http://shiflett.org/blog/...-mysql-real-escape-string

Uh; de conclusie luidt daar toch anders als volgt:

quote: http://shiflett.org/blog/...-mysql-real-escape-string

To avoid this type of vulnerability, use mysql_real_escape_string(), prepared statements, or any of the major database abstraction libraries.

En dan heb ik 't verder niet eens gelezen. En daarbij: 1 zwaluw maakt het nog geen lente

Meer hierover is ook in onze FAQ te vinden: Over het gebruik van Parametrized Queries

[ Voor 13% gewijzigd door RobIII op 23-07-2009 22:42 ]

[Gersomvg]

RobIII schreef op donderdag 23 juli 2009 @ 22:38:
Uh; de conclusie luidt daar toch anders als volgt:

Klopt.. ik heb het hele stuk gelijk maar even gelezen.. Maar ik doelde eigenlijk meer op het feit dat addslashes überhaupt wordt vergeleken op functionaliteit met mysql_real_escape_string. Ik gebruikte tot nu toe dus geen functie die echt een totaal ander doel dient.
Maar je hebt helemaal gelijk verder RobIII Misschien heb ik af en toe nog wat php-opvoedkundige feedback nodig maar het zal op den duur allemaal vast wel goed komen.. Ben me sinds een paar maanden heel erg aant verdiepen in al die netheids- en structuurregeltjes. Misschien niet het slimste idee om nu dan al anderen proberen te helpen door php-code te schrijven maar dat is iig goed bedoelt

[ Voor 8% gewijzigd door Gersomvg op 23-07-2009 22:48 ]

[_Sunnyboy_]

Wat betreft SQL injectie kun je nog beter gebruik maken van prepared statements met bind variables. Dan kan sql injectie echt niet meer aangezien de query eerst wordt geparsed door de database en hij dan pas de variabelen invult.

Prepare->Bind->Execute zit niet in de mysql library maar wel in mysqli en pdo_mysql.

[XWB]

Gersompie schreef op donderdag 23 juli 2009 @ 22:46:
[...]

Klopt.. ik heb het hele stuk gelijk maar even gelezen.. Maar ik doelde eigenlijk meer op het feit dat addslashes überhaupt wordt vergeleken op functionaliteit met mysql_real_escape_string. Ik gebruikte tot nu toe dus geen functie die echt een totaal ander doel dient.
Maar je hebt helemaal gelijk verder RobIII Misschien heb ik af en toe nog wat php-opvoedkundige feedback nodig maar het zal op den duur allemaal vast wel goed komen.. Ben me sinds een paar maanden heel erg aant verdiepen in al die netheids- en structuurregeltjes. Misschien niet het slimste idee om nu dan al anderen proberen te helpen door php-code te schrijven maar dat is iig goed bedoelt

Vergeet die hele mysql_ ellende en verdiep je in PDO.

[Verwijderd]

Hacku schreef op vrijdag 24 juli 2009 @ 23:45:
[...]


Vergeet die hele mysql_ ellende en verdiep je in PDO.

PDO is the way to go inderdaad. Wellicht moet je gevoelsmatig even omschakelen, had ik tenminste, maar dan merk je dat je echt zo onwijs snel queries kunt schrijven.

Snap overigens niet dat men dit niet vaker aanhaalt, zeker door de zogenaamde guru's. Wellicht is het zo dat mensen er echt even van geproefd moeten hebben om het aan te raden.

Ik zou zeggen... go for it !

[ Voor 5% gewijzigd door Verwijderd op 31-07-2009 00:01 ]