MSQL Error bij het invoeren
Ik krijg een heel raar error. Via een textarea probeer ik een tekst in database in te voeren. Als een tekst een -'- bevat krijgt ik een error. Bijvoorbeeld:
Sja's boek is weg. kan niet worden ingevoerd wegens die ' -. Dit is de error:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's test...
mysql_select_db("$dbname") or die("verkeerde database");
$SQLquery = "INSERT INTO webdb (writer, title, category, language, headline, essay, date)
VALUES('$writer', '$title', '$category', '$language', '$headline', '$essay', '$date')";
if (mysql_query ($SQLquery, $LinkID) or die(MySQL_Error()))
{
print ("Successfully added<br>");
}
else
{
print ("Could not execute query");
}
Code (php)
1
2
3
2
3
foreach (explode(' ', 'writer title category language headline essay date') as $var) {
$$var = mysql_real_escape_string($$var);
}
$$var = mysql_real_escape_string($$var);
}
voordat je de query uitvoert
Bas Cost Budde op 16/12/2010 23:33:09:
voordat je de query uitvoert
Code (php)
1
2
3
2
3
foreach (explode(' ', 'writer title category language headline essay date') as $var) {
$$var = mysql_real_escape_string($$var);
}
$$var = mysql_real_escape_string($$var);
}
voordat je de query uitvoert
Geen echt nette oplossing vind ik.
Maar het zal zeker werken.
Bas Cost Budde op 16/12/2010 23:33:09:
voordat je de query uitvoert
Code (php)
1
2
3
2
3
foreach (explode(' ', 'writer title category language headline essay date') as $var) {
$$var = mysql_real_escape_string($$var);
}
$$var = mysql_real_escape_string($$var);
}
voordat je de query uitvoert
Dit is niet echt een nette oplossing. Variabele variabelen zijn niet handig in gebruik.
De data die een gebruiker verstuurd kan je nooit vertrouwen. Daarom is het dus handiger om die data gewoon lekker in de $_POST array te laten zitten. Als je daaruit data haalt, dan weet je zeker dat deze data onveilig is. Met de oplossing van Bas hierboven weet je dat dus ook niet.
Zie php.net: mysql_real_escape_string hoe je net variabelen kan escapen.
Verder is het beter als je variabelen buiten quotes (") haalt. Variabelen binnen quotes stoppen en die mee geven als parameter aan functions zoals mysql_connect is helemaal nonsens. Je kunt gewoon de variabelen mee geven.
Ook is or die geen nette manier van foutafhandeling. Jou stukje code zal zelfs nooit bij de else komen door deze die.
Die gebruiken is niet net omdat je tegen je script zegt dat het dood moet vallen. Waarom zou je dat doen? Je kunt een script netjes afronden.
Edit: Verder wil je nooit een foutmelding van php of mysql aan je gebruiker tonen. Deze informatie kunnen zij misbruiken.
Jordi kroon op 16/12/2010 23:19:15:
Plaats je code eens
Code geven is in principe niet nodig. Aan de hand van de foutmelding kan je zien dat er dus geen escape op de query wordt gedaan.
Jij bent er nogal streng op he. Noem jij het onveilig omdat je aan de variabele niet kunt zien of het ruwe request-data is, of netjes behandelde waarden? Ik zou ze beter als zodanig kunnen aanduiden (_sc postfix of zo)--of natuurlijk een schappelijke wrapper om de query-call heenbouwen. Of werken met mysqli_prepare en familie. Beter zo?
@SanThe, van jouw bijdragen leer ik nogal eens iets. Zou jij het anders aanpakken, of willen verbeteren? Het fragment is uit een object uit mijn bedrijf gepikt (dat mag, want ik heb het opgezet) dat zich met requestdata bezighoudt; niet echt bedoeld voor in een "script" dus.
Bas Cost Budde op 17/12/2010 00:12:40:
@Karl karl, nadat mijn snippet heeft gedraaid zijn de variabelen geescapet, en dus in orde om de database in te gaan.
Ja, nadat je snippet heeft gedraaid. Dat is dus het punt. Daarvoor zijn er dus variabelen die gewoon gekopieerd zijn van $_POST. Daar zijn twee punten mis mee. Ze zijn gekopieerd en dus niet nuttig.
Het mooie aan de $_POST is dat je weet dat deze van de gebruiker vandaan komt, dat betekend dus dat dat je die data niet kan vertrouwen. Als je die data gaat kopiëren, dan kan je in de war raken met of ze al wel of niet veilig zijn.
Bas Cost Budde op 17/12/2010 00:12:40:
Jij bent er nogal streng op he. Noem jij het onveilig omdat je aan de variabele niet kunt zien of het ruwe request-data is, of netjes behandelde waarden?
Deze technieken zijn veel vaker toegepast en geadviseerd dan een of andere constructie met variabele variabelen.
Bas Cost Budde op 17/12/2010 00:12:40:
Ik zou ze beter als zodanig kunnen aanduiden (_sc postfix of zo)--of natuurlijk een schappelijke wrapper om de query-call heenbouwen. Of werken met mysqli_prepare en familie. Beter zo?
Volgens mij heb je het niet helemaal begrepen. Maar als je $_POST variabelen gaat kopiëren met een pre- / postfix dan kan je toch net zo goed $_POST gebruiken?
Ja, met prepared statements ben je helemaal van het probleem af.
Bas Cost Budde op 17/12/2010 00:12:40:
@SanThe, van jouw bijdragen leer ik nogal eens iets. Zou jij het anders aanpakken, of willen verbeteren?
Mag ik vragen hoezo je iets leert van Santhe en niet van mij, terwijl wij ongeveer (eigenlijk precies) hetzelfde schrijven?
Bas Cost Budde op 17/12/2010 00:12:40:
Het fragment is uit een object uit mijn bedrijf gepikt (dat mag, want ik heb het opgezet) dat zich met requestdata bezighoudt; niet echt bedoeld voor in een "script" dus.
Kan je dat uitleggen, wat je bedoelt met requestdata?
Karl Karl op 17/12/2010 00:26:16:
Ja, nadat je snippet heeft gedraaid. Dat is dus het punt. Daarvoor zijn er dus variabelen die gewoon gekopieerd zijn van $_POST. Daar zijn twee punten mis mee. Ze zijn gekopieerd en dus niet nuttig.
Bas Cost Budde op 17/12/2010 00:12:40:
@Karl karl, nadat mijn snippet heeft gedraaid zijn de variabelen geescapet, en dus in orde om de database in te gaan.
Ja, nadat je snippet heeft gedraaid. Dat is dus het punt. Daarvoor zijn er dus variabelen die gewoon gekopieerd zijn van $_POST. Daar zijn twee punten mis mee. Ze zijn gekopieerd en dus niet nuttig.
Dus: mysql_real_escape_string($_POST['opmerking'])?
Karl Karl op 17/12/2010 00:26:16:
Het mooie aan de $_POST is dat je weet dat deze van de gebruiker vandaan komt, dat betekend dus dat dat je die data niet kan vertrouwen. Als je die data gaat kopiëren, dan kan je in de war raken met of ze al wel of niet veilig zijn.
Deze technieken zijn veel vaker toegepast en geadviseerd dan een of andere constructie met variabele variabelen.
Volgens mij heb je het niet helemaal begrepen. Maar als je $_POST variabelen gaat kopiëren met een pre- / postfix dan kan je toch net zo goed $_POST gebruiken?
Ja, met prepared statements ben je helemaal van het probleem af.
Bas Cost Budde op 17/12/2010 00:12:40:
Jij bent er nogal streng op he. Noem jij het onveilig omdat je aan de variabele niet kunt zien of het ruwe request-data is, of netjes behandelde waarden?
Deze technieken zijn veel vaker toegepast en geadviseerd dan een of andere constructie met variabele variabelen.
Bas Cost Budde op 17/12/2010 00:12:40:
Ik zou ze beter als zodanig kunnen aanduiden (_sc postfix of zo)--of natuurlijk een schappelijke wrapper om de query-call heenbouwen. Of werken met mysqli_prepare en familie. Beter zo?
Volgens mij heb je het niet helemaal begrepen. Maar als je $_POST variabelen gaat kopiëren met een pre- / postfix dan kan je toch net zo goed $_POST gebruiken?
Ja, met prepared statements ben je helemaal van het probleem af.
Dat idee van postfixen van variabelen om aan te geven of het over ruwe data gaat (dus bijvoorbeeld verkregen uit request) komt, geloof ik, uit Symfony.
Bas Cost Budde op 17/12/2010 00:12:40:
@SanThe, van jouw bijdragen leer ik nogal eens iets. Zou jij het anders aanpakken, of willen verbeteren?
Mag ik vragen hoezo je iets leert van Santhe en niet van mij, terwijl wij ongeveer (eigenlijk precies) hetzelfde schrijven?
Huh, dat bedoelde ik helemaal niet hoor, sorry :) Mijn reactie op jou was afgelopen.
Bas Cost Budde op 17/12/2010 00:12:40:
Het fragment is uit een object uit mijn bedrijf gepikt (dat mag, want ik heb het opgezet) dat zich met requestdata bezighoudt; niet echt bedoeld voor in een "script" dus.
Kan je dat uitleggen, wat je bedoelt met requestdata?
[/quote]
requestdata is wat ik uit $_REQUEST aan informatie haal. De URI, GET-parameters, POSTdata. Alles komt van buiten, dus alles is met argwaan te behandelen.