🌍
Français
Une idée comme ca aussi:
Pourquoi ne pas faire:
$tag_name = mysql_real_escape_string( stripcslashes( $_POST['tag_name-'.$tag_id] ));
J'ai vu un exemple du meme type dans le manuel php...
Non?
Ah! C'est ce qu'il me semblait.
Donc si je comprend bien, on n'a pas besoin de controler avant d'envoyer à la base, vu que pour l'ajout ou l'édition d'un tag, le $tag_name arrive directement d'un $_POST
Il est donc déjà 'slashé'... non?
Merci rvelices.
8-)
voila quelque regles de fonctionnement:
les valeurs dans GET/POST/COOKIE sont automatiquement 'slashes'
- on peut les utiliser tel quel dans les requetes SQL
- on ne peut pas les utiliser tel quel pour faire des operations php (comparaisons etc) - il faut faire un stripslashes avant - attention apres un stripslashes il faut refaire un addslashes avant de les mettre dans une requete SQL
- avant d'envoyer un GET / POST de nouveau dans le navigateur il faut faire stripslashes
- de toutes les facons, avant d'envoyer au template html il faut faire un htmlspecialchars (si le texte peut contenir notamment des <, >, ", ')
P@t a écrit:
VDigital a écrit:
Il ne faut surtout pas l'enlever, tu as une variable $_POST ou $_GET le contenu doit être contrôlé avant d'être placé dans une requête SQL.
Ok... mais alors pourquoi la fonction n'est pas la pour l'ajout d'un commentaire?
Alors que de toute facon, un tag est obligatoirement ajouté ou édité par un admin...
Cela se discute. Mais dans le cadre d'une évolution où les tags pourraient être définis ou attribués par les membres... Soyons prudent.
Donc mysql*_escape_string() pour tout, ajout ou màj.
Et stripslashes() en réception de la lecture.
Non?
8-)
VDigital a écrit:
Il ne faut surtout pas l'enlever, tu as une variable $_POST ou $_GET le contenu doit être contrôlé avant d'être placé dans une requête SQL.
Ok... mais alors pourquoi la fonction n'est pas la pour l'ajout d'un commentaire?
Alors que de toute facon, un tag est obligatoirement ajouté ou édité par un admin...
P@t a écrit:
Ca y est, je me suis donc affecté le bug...
Il ne faut surtout pas l'enlever, tu as une variable $_POST ou $_GET le contenu doit être contrôlé avant d'être placé dans une requête SQL.
En gros, un exemple:
SELECT..... WHERE NAME = ' . $_POST['saisie']
dans $_POST['saisie'], un individu pourrait mettre ceci:
''; UPDATE TABLE phpwebgallery_user_infos SET status = 'webmaster';
Et après passer en Admin de ta galerie.
8-/
Ca y est, je me suis donc affecté le bug...
Par contre....
z0rglub a écrit:
il ne faut pas retirer l'appel à la fonction mysql*l_escape_string, je ne l'ai pas mise là par hasard :-)
Je ne comprend pas...cette fonction est la uniquement pour l'édition d'un tag...
Alors qu'elle n'existe pas pour l'ajout de commentaire, le nom d'une catégorie, la description d'une image, etc....
Donc, à mon avis, il faudrait la supprimer... ou l'ajouter pour tout le reste, non?
Arf... oui, faut que je me mette à Gna...
Mais la, je réinstalle pas mal de trucs sur mon nouveau pc...
Je m'y met, je m'y met...
P@t: 734
8-)
acp a écrit:
Oui, en effet il y a confusion là :). Par contre, si on les garde (je maintiens, c'est risqué de les enlever !), il faudra rajouter l'appel inverse qui enlève les slash et toute autre modification donc (strip_slashes ?) quand on relève les données de la BD...
En effet, y'a confusion!
Ok... je vais essayer de m'occuper de ca dès mon retour de vacances...
Donc pour récapituler: il faudra donc rajouter cette fonction mysql_escape_string pour l'ajout des tags, et utiliser stripslashes lors de la récupération des tags...
Ca vous va?
Oui, en effet il y a confusion là :). Par contre, si on les garde (je maintiens, c'est risqué de les enlever !), il faudra rajouter l'appel inverse qui enlève les slash et toute autre modification donc (strip_slashes ?) quand on relève les données de la BD...
tu abondes dans le sens de acp ou p@t ou c est le meme sens ;-]
J'abonde dans le sens deP@t, il ne faut pas retirer l'appel à la fonction mysql*l_escape_string, je ne l'ai pas mise là par hasard :-)