Salut a tous,
 
Vous vous explique mon problème, j'ai un panier sur mon site e-commerce et j'ai un champ $_POST pour changer la quantité, Mais j'ai trouvé 2, 3 bug.
Je peut mettre 2.3, mais je peut peut pas commander 2.3 quantité d'un produit, alors comment avoir que des nombre entier? il y a sûrement une fonction PHP mais je la connais pas
J'ai aussi trouvé que quand je met 2,3 , la "," me fait buger mon code Mysql, alors comment faire pour avoir que des nombre numérique et pas de caractère spéciaux ou de lettre? il y a sûrement aussi un fonction et la sa réglerait aussi mon premier bug. Voila Merci beaucoup.  

ctype_digit

ok Merci

et y aurai pas une fonction comme elle mais à la place a vérifier si il y a des entiers, qu'elle enlève tous se qu'il n'est pas et qu'elle laisse que des nombres? Merci

preg_replace('/[^0-9]/', '', $tontruc)

ok Merci

intval ne fait pas ça ?

Je voulais savoir autre chose, Je voudrai savoir si on peut passer par $_GET un champ de formulaire? Je m'explique, la visiteur sur la fiche du produit rentre la quantité qu'il veut et valide, et je voudrai passer cette quantité par $_GET? est-ce possible? Ou il faut vraiment que je passe par $_POST? Merci

La Fonction de sielfried marche très bien, je sais pas pourquoi je n'y avais pas penser. Sûremet car je l'utilise trop peut.

je préfère faire intval que preg_machin

Ça dépend ce qu'il veut. intval (ou un cast en int, ce qui revient à peu près au même je crois) est probablement plus adaptée, mais j'ai répondu strictement à sa question. intval ne fait pas que virer les non-chiffres, c'est une fonction numérique.        

 
<form method="get"

Il faut que ça soit du POST obligatoirement, car l'action a des effets de bords.

intval transforme 2,3 - 2.3 - "2.3" et "2,3" en 2
c'est ce qu'il voulait

 
Une fonction qui vire tout ce qui n'est pas numérique dans "2,3" retourne "23", pas 2. intval est probablement plus adapté à son cas mais sa question était dans ce cas très mal formulée.  
 
Bref.

 
Si, elle apparaîtra dans l'URL. De toute façon c'est une très mauvaise idée comme l'a signalé FlorentG. Quel est le but ?

aaaah je n'avais effectivement pas compris ça comme ça
 

C'est bon j'ai compris comment ça marchait .  
En fait j'ai un produit à vendre, le visiteur sélectionne la quantité dans un champ et après il valide et est redirigé  vers le panier.
Mais ouiat je pense que POST est le plus propre.

ouiat aussi d'un coté c'est peut être mieux.  Mais bon je pense que je vais laisser comme ça.

je voulais savoir un autre truc, est-ce que cette requête est juste? Merci
 
mysql_query('INSERT INTO lcg_boutique_commandes VALUES('','.$date_commande.','.$_SESSION['id_client'].','','.$_POST['total_commande'].','.$_POST['paiement'].','','','.1.','.$donnees_client['nom'].','.$donnees_client['prenom'].','.$donnees_client['adresse'].','.$donnees_client['adresse2'].','.$donnees_client['code_posta'].','.$donnees_client['ville'].','.$donnees_client['code_pays'].','','.$donnees_client['pays'].')') or die(mysql_error());

Salut,
ton code est très dangereux comme ça, en fait on peut aisement faire des injections sql pour peu qu'on s'y connaisse.
 
Je te conseille de récupèrer tous tes posts dans des variables comme ceci :
 
$truc = htmlspecialchars(addslashes($_POST['valeur']));
 
Ca résout également le problème des virgules qui font bugguer le code et ton code est plus sécurisé.
 
D'ailleurs ne laisse surtout pas la fonction mysql_error() dans la version finale de ton site, si les visiteurs voient l'erreur retournée ça facilitera la tâches des injections sql...
 
 
Sinon, j'aurais plutôt fait :
(...) VALUES('".$date_commende."', '".$_SESSION['id_client']."', (...)

ok Merci beaucoup pour cette aide, je vais faire comme tu dit.
EDIT: Sa sert a rien de le faire sur les données récupéré dans une BDD et après réenregistré?

vaut mieux faire B, voire même C
 
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

 
Du moment que c'est du $_POST (ou du $_GET), peu importe d'où proviennent les données... tu dois le faire !
 
par ailleurs merci à art_dupond pour la précision, en effet il est mieux de faire :
 
$truc = htmlspecialchars(mysql_real_escape_string($_POST['valeur']));  
 

à noter qu'il faut d'abord ouvrir la connexion à la DB avant de pouvoir utiliser mysql_real_escape_string() (enfin si je ne parkinsonise pas déjà trop).

 
OK merci pour toutes ces précisions.    

Surtout pas de htmlspecialchars à ce niveau là. La donnée sera insérée dans la base, il suffit de la protéger en vue d'une injection SQL.
 
L'htmlspecialchars interviendra au moment de l'affichage.

En effet htmlspecialchars n'a strictement rien à faire là.

Je ne vois pas en quoi ça gêne un htmlspecialchars ?
 
Pouvez-vous détailler un peu plus svp ?

 
C'est absolument pas fait pour ça. C'est une fonction d'affichage, pas de protection des données.

Bon, je sais que c'est pas propre, mais si on fait tout le temps comme ça et pour tous les POST, à priori il n'y aura pas de problème, non ?

 
Il vaut mieux comprendre ce que fait chaque fonction plutôt que de les combiner un peu au hasard pour "protéger les variables de tout".  
 
mysql_real_escape_string (ou mieux, des prepared statements avec PDO/mysqli) permet d'échapper de façon sécurisée une donnée à insérer dans une base MySQL. htmlspecialchars et les fonctions du genre permettent de transformer les caractères spéciaux du html en leur équivalent en entités "non interprétées", donc notamment pour protéger des attaques XSS lorsqu'on affiche un truc saisi par l'utilisateur.
 
Les deux choses sont complètement différentes.

Et si t'as besoin de la donnée ailleurs que dans l'HTML ?

 
http://fr.php.net/manual/fr/functi [...] decode.php voyons !  

Ben oui hein, namého    
 
 
(tapez pas ! c'était juste une question   )

Si ce sont des données de toute façon destinées à être affichées, *chien de mickey* que de htmlspecialchariser à chaque fois, pourquoi ne pas le faire une fois pour toute ?

Perso je ne le fais pas parce que je me dis qu'il se pourrait qu'un jour j'utilise les données autrement (puis y a le cache), mais sinon je vois pas pourquoi c'est "si" mal

edit: oups, j'ai un peu mis de temps à poster

Sinon, suffit de se faire sa fonction qui échappe les trucs et au pire de modifier le jour où on a besoin des données autrement - ce que je faisais puis je n'ai jamais eu besoin des données autrement

Parceque ca modifie les données a l'enregistrement alors que normalement on le fait à l'affichage, utiliser mysql_real_escape_string() permet d'eviter de modifier, tout en sécurisant ses requétes.
 
Si tu utilises addslashes(), tu seras obligé d'utiliser stripslashes() aussi, quand à htmlspecialchars() ca peut te poser des problèmes avec l'encodage et d'autres trucs.

la question est : pourquoi absolument le faire à chaque affichage au lieu de ne le faire qu'une fois à l'enregistrement (si ça marche, qu'il n'y a pas de problème...)