Je développe un système de login où je DOIS autoriser les caractères spéciaux. Bon je suis habitué des devs en PHP/MYSQL, mais là y'a un truc qui doit m'échapper.
J'ai donc en test un utilisateur qui veut s'appeler "Test'Login" (sans guillemets mais avec apostrophes). Donc je l'insère en BDD avec protection contre injections sql donc dans ma table : user_login = Test\'Login
Le truc c'est que je n'arrive pas avec un select à récupérer cet utilisateur. Même sous phpmyadmin en faisant un tout simple SELECT*FROMusersWHERuser_loginLIKE'Test\'Login'
ne marche pas. J'ai essayé pas mal de trucss genre double salsher et tout mais peut etre je le fais mal.
Et de plus, même en passant par l'outil de recherche phpmyadmin, je tape donc dans le champ de recherche user_login Test'Login et il ne me trouve rien !
Aucune erreur donc, mais à chaque fois aucun résultat trouvé !!!
Merci d'avance
Tangooo.
Edit : Oula, alors sous phpmyadmin pour pouvoir le récupérer je dois tout double slasher donc faire LIKE 'Test\\\'Login' Quelqu'un peut m'expliquer pourquoi ? Et surtout donc je dois appliquer deux fois mysql_real_escape_string ??? (je vois bien que c'est la solution mais en quoi c'est logique ?)
Ton server est mal configuré, si tu as des antislashes dans ta BDD, c'est que tu n'as pas désactivé le magic_quote_gpc.
Commence par là, nettoie ta BDD à la main et recommence tes tests de recherche, ça devrait fonctionner.
mres() ne rajoute pas d'antislashes dans la BDD, c'est addslashes qui le fait (ou le magic_quote_gpc)
Pour désactiver le magic_quote_gpc, si tu es en local, commente la ligne dans le php.ini sinon, cette directive dans un .htaccess fera l'affaire
# Désactivation magic_quote_gpc et magic_quote_runtime
php_flag magic_quotes_gpc off
php_flag magic_quotes_runtime off
Après cela, ta BDD sera propre et jolie. Comme tu sembles utiliser mres() sur tes variables avant d'interagir avec la BDD, elle ne craint rien, les requêtes sont protégées contre l'injection SQL.
mres() ne rajoute pas d'antislashes dans la BDD, c'est addslashes qui le fait (ou le magic_quote_gpc)
mres() ou addslashes() transforment tous les deux ' en \'.
Faut simplement ne pas inserer avec addslashes() [à cause des magic_quotes] + mres(), qui transforment ' en \\' et donc stockent \'
J'insiste.
magic_quote_gpc à off + mres() et tu n'auras pas d'antislashes dans la BDD devant les apostrophes !
mres() se contente de protéger les données contre l'injection SQL pendant l'exécution de la requête, c'est tout
Et si son serveur ne prend pas les directive que Zazou à proposer, tu peux toujours utiliser cette fonction sur toutes les variables à protéger pour ta requête :
<?php
function mysql_protect( $string )
{
// Empéche les injections SQL pour les requètes ; à utiliser sur toutes les varibles provenant de $_POST ou $_GET ou $_COOKIE
if ( get_magic_quotes_gpc ( ) )
{
return mysql_real_escape_string ( stripslashes ( $string ) ) ;
}
else
{
return mysql_real_escape_string ( $string ) ;
}
return false ;
}
?>
J'avais déjà désactivé les magic_quotes et j'utilise mres() et pas addslashes(). Pas de souci de ce côté là.
Edit : Ok, c'est bon j'ai trouvé. En fait quand j'insérais les logins en base de données, ce code a été fait avant que je ne désactivé les magic quotes, et les tests d'insertion ont été fais quand il y avait les magic quotes d'activés.
Avec les nouvelles insertions sans les magic quotes, celà marche très bien, il n'y avait pas de problème en fait, juste des décalages de tests...Merci à tous quand même.
Et tiens pour les gens qui veulent désactiver les magics_quotes sur un mutualisé, c'est cadeau
mres() n'échappe les apostrophes que AVANT et PENDANT la requête mais il ne les enregistre pas dans la BDD ! Donc c'est normal !
<?php
// Connexion + fonction mres() inclues ici
$var = 'J\'utilise une apostrophe';
echo $var,'<br/>';
$var = mres($var);
echo $var,'<br/>';
$sql = 'INSERT INTO test (message) VALUES ("'.$var.'")';
mysql_query($sql);
$sql = 'SELECT message FROM test';
$req = mysql_query($sql);
$row = mysql_result($req,0);
echo $row;
/*
Retour avec magic_quote_gpc à off :
J'utilise une apostrophe
J\'utilise une apostrophe
J'utilise une apostrophe
Retour avec magic_quote_gpc à on :
J'utilise une apostrophe
J\'utilise une apostrophe
J\'utilise une apostrophe
*/
Vous amalgamez systématiquement protection (dans le sens de sécurité ce qui ne veut rien dire) et échappement qu'on doit OBLIGATOIREMENT utiliser quelque soit la provenance des chaines et qui sert simplement à les préparer à être "incluses" dans des languages ou formats tiers (html, xml, sql, php, regexp, url, json, etc...) pour ne pas en modifier la structure. La façon d'échapper les chaines dépendant donc du language ou format désiré.
C'est dingue que ce truc fondamental ne soit pas compris, toutes les réponses sont vagues et tiennent de la recette, les fonctions de la magie...
@Zazou: si tu reprends ton dernier test en remplaçant mres() par addslashes() tu verras que ça marche aussi...
où est passé le pouvoir de mres() que tu sembles vouloir nous indiquer ?
Il me semble que pour échapper un caractère en SQL (et j'en suis quasiment sûr), il ne faut pas un slashes mais doubler le caractère en question donc addslashes ne doit pas échapper correctement pour du SQL ...
Ensuite Tracker, pour le fait qu'il faut échapper toutes données, je suis d'accord avec toi sauf sur un mot de passe haché en md5 ou sh1, c'est inutile puisque aucun caractère sensible ne ressort après le hachage !
Toujours pareil :
Ce que dis Tracker semble sûr et fiable.
Toutefois, et je me répète : Pourquoi perdre son temps à poster 1000 fois la même information alors qu'un tutoriel suffirait à combler les manques de connaissances des zér0s ?
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Il me semble que pour échapper un caractère en SQL (et j'en suis quasiment sûr), il ne faut pas un slashes mais doubler le caractère en question donc addslashes ne doit pas échapper correctement pour du SQL ...
Tu te plantes:
Citation : doc
mysql_real_escape_string() appelle la fonction mysql_escape_string() de la bibliothèque MySQL qui ajoute un slash aux caractères suivants : NULL, \x00, \n, \r, \, ', " et \x1a
Addslashes() Retourne la chaîne str , après avoir échappé tous les caractères qui doivent l'être, pour être utilisée dans une requête de base de données. Ces caractères sont les guillemets simples ('), guillemets doubles ("), antislash (\) et NUL (le caractère NULL)
La seule différence c'est que MySQL attend que les sauts de ligne et les caractères 1a et 0 soient également échappés. C'est pour celà que mres() est à utiliser et pas addslashes(), mais si je prends ta logique à la noix, si ma chaine de contient ni retour à la ligne ni caractère (1a ou 0), je peux utiliser addslashes()...
Citation : Roadkiller
Ensuite Tracker, pour le fait qu'il faut échapper toutes données, je suis d'accord avec toi sauf sur un mot de passe haché en md5 ou sh1, c'est inutile puisque aucun caractère sensible ne ressort après le hachage !
C'est pas parce quelques chaines compte tenu de leur nature (sha1, base64 etc...) ne contiennent pas de caractère SQL (ou html etc...) problématique qu'il faille faire des cas particuliers et s'interdire le confort de généraliser le principe. Les requêtes PDO préparées ou des systèmes de sortie HTML managés (objet View) montre qu'il est 1000 fois plus pertinent de généraliser car le développeur à autre chose à faire que s'étendre sur ce type de détail, et d'ailleurs quand il en a la responsabilité bien souvent il se plante (y'a qu'à regarder les posts sur le sujet dans le SDZ).
@mrjay42: y'a déjà de mémoire au moins deux tutos racontant n'importe quoi sur le sdz, celui de mattéo et un autre conseillant l'utilisation de addcslashes()... C'est pas des tutos qu'il faut mais des validateurs compétents et un grand ménage...
Effectivement Tracker, je viens de tester il n'y a pas d'antislash dans la BDD avec addslashes
Donc les 2 fonctions ont les mêmes objectifs, mais mres() échappe plus de caractères spéciaux, d'où le fait qu'il faille le privilégier.
J'ai toujours cru qu'addslashes ajoutait physiquement un slash devant les caractères à échapper, mais à l'époque de mes constats (c'était il y a bien longtemps maintenant), j'avais donc seulement le magic_quote_gpc d'actif.
"J'ai toujours cru qu'addslashes ajoutait physiquement un slash devant les caractères à échapper"
C'est le cas, sauf que le parser mysql va les retirer.
Nan mais j'ai compris pas la peine d'en rajouter une couche -_-
J'ai précisé physiquement, fallait ptète que j'le mette en gras et rouge pour qu'il ne soit pas zappé ?
Quand je dis physiquement c'est qu'on les retrouve dans la BDD par la suite, comme le fait le magic_quote_gpc
Donc pas physiquement c'est le comportement normale des 2 fonctions.
@mrjay42: y'a déjà de mémoire au moins deux tutos racontant n'importe quoi sur le sdz, celui de mattéo et un autre conseillant l'utilisation de addcslashes()... C'est pas des tutos qu'il faut mais des validateurs compétents et un grand ménage...
Tracker.
Mais je ne demande pas mieux !
Je te propose de participer à tout ça, autrement qu'en écrivant de manière sporadique quelques posts contenant la précieuse connaissance
Améliorons la qualité de ce site et créons nos propres tutoriels.
Je pense avoir le niveau suffisant pour rédiger pas mal de choses sur PHP et désormais sur Zend (j'ai vraiment envie d'écrire un tuto sur l'utilisation de Zend Framework en partant de zér0s)...
Idem concernant, SQL.
Sur le net français il n'y a aucune source fiable pour apprendre à faire une application web avec Zend Framework depuis zér0.
En effet, les tutos, notamment ceux de J.Pauli sur développez.com s'adressent à un public connaissant déjà les frameworks et/ou les designs patterns (MVC compris)
Idem, concernant le bouquins du même auteur (J.Pauli, ZF bien developper en PHP), que j'ai acheté, et qui est surtout remplis de vide :
Rien sur Zend_Form
Rien sur les validateurs
Rien sur les décorateurs
QUE DALLE...
Bref, y'a une place à prendre.
Tracker, tu as les compétences et l'expérience.
Moi j'ai un peu des deux, mais en moins grandes quantités...
Je ne demande pas mieux que d'aider la communauté en t'aidant toi à rédiger un tutoriel.
Au pire, ça peut se faire sans toi.
Mais ce serait vraiment dommage, parce qu'on perdrait en fiabilité.
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
@Tracker: Je sais ce que je dis, en SQL on peut échapper un ' ou un " en le doublant (ce qui donne '' et "" )
Citation : Doc MySQL
Il y a plusieurs façons d'intégrer un guillemet dans une chaîne :
*
Un ‘'’ à l'intérieur d'une chaîne entourée de ‘'’ peut être noté ‘''’.
*
Un ‘"’ à l'intérieur d'une chaîne entourée de ‘"’ peut être noté ‘""’.
*
Vous pouvez faire précéder le guillemet par caractère d'échappement (‘\’).
*
Un guillemet simple ‘'’ à l'intérieur d'une chaîne à guillemets doubles ‘"’ n'a besoin d'aucun traitement spécial (ni doublage, ni échappement). De même, aucun traitement spécial n'est requis pour un guillemet double ‘"’ à l'intérieur d'une chaîne à guillemets simples ‘'’.
Bon je l'accorde, ça ne fonctionne que pour les ' ou les " suivant lequel des deux entoure la chaine de caractère mais cela existe
Pour les autres caractères, il leur faut un slashe, autant pour moi !
Pour le reste, tu m'as convaincu (sur le fait de généraliser)
PS: si vous faites un tuto correct, j'irai le lire de ce pas
Requete MYQSL apostrophe
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)
Si y'a pas d'accents dans mes messages c'est parce que je suis sur un clavier norvegien :)