Requête sensible a la casse [Résolu]

[Royade]

Bonsoir, j'ai un petit soucis quand je veux voir si un pseudo existe dans ma base de donnée, ma requete est sensible a la casse, la requete preparé est lié au traitement javascript; j'ai la même requete quand le formulaire est envoyer pour refaire des verifications et elle fonctionne correctement. (interclassement: utf8_general_ci)
Si quelqu' un a une petite idée

code js

Code javascript :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if(texte = file('verifpseudo.php?pseudo='+escape(lepseudo)))
{
  if(texte == 1)
  {
     writediv_pseudo('<p class="icone_inscription"><img src="/images/icone_no.png" /><p class="message_inscription_erreur">Ce pseudo est  déjà utilisé par un membre, veuillez en choisir un autre</p>');
  }
  else if(texte == 2)
  {
    pseudo.style.borderColor = "#a0a0a0";	
    writediv_pseudo('<p class="icone_inscription"><img src="/images/icone_ok.png" /></p>');
  }	
  else
  {
    writediv_pseudo(texte);
  }
}

page verifpseudo.php

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$son_pseudo = htmlspecialchars($_GET["pseudo"]);
/*$son_pseudo = strtolower($son_pseudo);*/
 
$repons = $bdd->prepare('SELECT COUNT(*) AS nbr_pseudo FROM membres WHERE LOWER(login) = LOWER(:pseudo) '); // On compte le nombre de login qui ont la même valeur que celle rentré à l'instant par l'utilisateur.
$repons->bindValue('pseudo',$son_pseudo , PDO::PARAM_STR);
$repons->execute();
 
	$free_pseudo = ($repons->fetchColumn()==0)?1:0;
 
$repons->closeCursor();
 
if(!$free_pseudo){echo "1";}
else{echo "2";}
?>

[sabotage]

Tes pseudos sont stockés avec des entités HTML ? Si oui c'est une drôle d'idée.
Egalement tu pourrais utiliser XMLHttpRequest plutôt qu'un bidouillage.

Sinon je ne vois pas ce qui rendrait ton test sensible à la casse, as-tu debugué un peu pour voir a quel niveau de ton code commençait le problème ?

[Royade]

Tes pseudos sont stockés avec des entités HTML ? Si oui c'est une drôle d'idée.
Egalement tu pourrais utiliser XMLHttpRequest plutôt qu'un bidouillage.

Du tout, htmlspecialchars() n'a rien a faire la et j'utilise XMLHttpRequest.

En effet j'ai debugué et j'ai pu remonté au problème.. ca a mis le temps mais j'ai trouvé, merci quand même pour ta réponse

[RunCodePhp]

Salut

ma requete est sensible a la casse

Le fonctionnement que tu as ne s'y prêterait pas pour une table sensible à la casse, mais plutôt insensible à la case (utf8_general_ci).

Le simple fait de devoir utiliser la fonction LOWER() coté SQL serait un signe comme quoi ...

Imaginons le scénario suivant.
Au départ un internaute s'inscrit avec très exactement le pseudo suivant : éric
Donc dans la BDD "éric" sera enregistré, même en appliquant la fonction LOWER().

Quelques jours plus tard, ce même internaute, pas très au fait des ces histoire de "casses" au passage, a la mauvaise idée de saisir Eric comme pseudo lors de la phase d'identification.
Et bien au niveau de la requête SQL, il sera recherché "eric" et non "éric".
-> eric n'étant pas équivalent à éric, la requête SQL renverra rien, ou pire, trouvera un résultat qui ne correspondra pas à cet internaute, mais un autre (pas loin d'être une usurpation d'identité lié à un bug du programme/Site Web à mon sens).


A mon sens il vaudrait mieux s'orienter vers du insensible à la casse, et considérer que (en reprenant cet exemple) éric, eric, Éric, Eric, eRic etc, etc ... sera pour un seul et unique internaute.
En somme, ne pas pouvoir enregistrer 2 personnes différentes, une avec Eric et une autre avec eRiC, etc ...


Maintenant, je peux me tromper, faut voir

[rawsrc]

Ou le plus simple : utiliser un email en guise de login.

[RunCodePhp]

Envoyé par rawsrc

Ou le plus simple : utiliser un email en guise de login.

+1

D'ailleurs, se baser sur 1 seule donnée, qui plus est un pseudo c'est hyper risqué.
Au minimum, et pour une seule donnée, on impose un chaine la plus aléatoire possible, encore que ...

Ca risque fort d'être un jeu d'enfant de s'identifier à la place d'un autre, ça peu même être un jeu tout court, bonjour la réputation après


De mon coté je suis plus adepte d'exploiter au moins 2 données, ne serait-ce que pour augmenter les improbabilités.
mail + pseudo, qui n'est qu'autre que le fonctionnement que quasi tous font (login/pass).