Bug étrange et très très ennuyant
-Shadow-
Messages postés
2152
Date d'inscription
Statut
Membre
Dernière intervention
-
-Shadow- Messages postés 2152 Date d'inscription Statut Membre Dernière intervention -
-Shadow- Messages postés 2152 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
je reposte encore un problème car cela se passe depuis plusieurs jours. C'est très gênant.
Donc voilà. Sur mon site j'ai un système de commentaires, similaire à Commentcamarche.net pour simplifier l'explication: y'a un Textarea pour entrer le commentaire, et un bouton "Envoyer". Le textarea se nomme "umess" (UserMessage). Tout marche sur ce côté-là, tout est bien affiché.
Ce commentaire est, dès qu'on appuie sur "Envoyer", soumis à une requête POST vers un fichier PHP qui traite le texte et qui le publie ensuite sur la page concernée (via une insertion SQL). Et c'est ici que le bug arrive. En effet, je traite toutes les informations, TOUTES fonctionnent et sont ajoutées à la base de données des commentaires. Sauf une, miraculeusement ignorée.
Voici la liste des données envoyées au fichier PHP et inscrites dans la BDD :
* Date du message en format SQL (Y-m-d);
* Identificateur de l'utilisateur pour obtenir son nom dans le titre du message par la suite;
* Identificateur de la page actuellement visitée (Où ira le commentaire une fois inscrit dans la BDD, puis où l'utilisateur sera redirigé);
* Contenu du message (codé en HTML et avec des slashs ajoutés pour éviter l'injection SQL et l'injection HTML).
C'est là que c'est vraiment flippant: toutes les données sont correctement inscrites, date, utilisateur, identificateur de la page, sauf le contenu du message qui apparaît vide ET dans la page de commentaires, ET dans la BDD. Je n'y comprends rien... Il m'est même arrivé de supprimer le commentaire via PhpMyAdmin, côté BDD, pour le voir miraculeusement réapparaître... Avec le contenu révélé !! O_____o
Je suis complètement ahuri devant ce bug, et vu que je m'y connais en SQL autant qu'en programmation exotique, j'aimerais qu'on puisse me répondre à ce bug autant mystérieux que dérangeant. Si cela nécessite que je publie des morceaux de code, je le ferai volontiers.
Cdt
Matthias
je reposte encore un problème car cela se passe depuis plusieurs jours. C'est très gênant.
Donc voilà. Sur mon site j'ai un système de commentaires, similaire à Commentcamarche.net pour simplifier l'explication: y'a un Textarea pour entrer le commentaire, et un bouton "Envoyer". Le textarea se nomme "umess" (UserMessage). Tout marche sur ce côté-là, tout est bien affiché.
Ce commentaire est, dès qu'on appuie sur "Envoyer", soumis à une requête POST vers un fichier PHP qui traite le texte et qui le publie ensuite sur la page concernée (via une insertion SQL). Et c'est ici que le bug arrive. En effet, je traite toutes les informations, TOUTES fonctionnent et sont ajoutées à la base de données des commentaires. Sauf une, miraculeusement ignorée.
Voici la liste des données envoyées au fichier PHP et inscrites dans la BDD :
* Date du message en format SQL (Y-m-d);
* Identificateur de l'utilisateur pour obtenir son nom dans le titre du message par la suite;
* Identificateur de la page actuellement visitée (Où ira le commentaire une fois inscrit dans la BDD, puis où l'utilisateur sera redirigé);
* Contenu du message (codé en HTML et avec des slashs ajoutés pour éviter l'injection SQL et l'injection HTML).
C'est là que c'est vraiment flippant: toutes les données sont correctement inscrites, date, utilisateur, identificateur de la page, sauf le contenu du message qui apparaît vide ET dans la page de commentaires, ET dans la BDD. Je n'y comprends rien... Il m'est même arrivé de supprimer le commentaire via PhpMyAdmin, côté BDD, pour le voir miraculeusement réapparaître... Avec le contenu révélé !! O_____o
Je suis complètement ahuri devant ce bug, et vu que je m'y connais en SQL autant qu'en programmation exotique, j'aimerais qu'on puisse me répondre à ce bug autant mystérieux que dérangeant. Si cela nécessite que je publie des morceaux de code, je le ferai volontiers.
Cdt
Matthias
A voir également:
- Bug étrange et très très ennuyant
- Bug chromecast - Guide
- Iptv bug forum ✓ - Forum Box et Streaming vidéo
- Bug localisation snap ✓ - Forum Snapchat
- Savoir qui regarde notre localisation ? - Forum Snapchat
- Bug snap message invisible - Forum Snapchat
14 réponses
Non ça n'est pas logique.
Mais la suppression devrait supprimer le commentaire, la réapparition n'est elle-même pas possible, ce n'est pas magique non plus.
Il y a moyen d'avoir un exemple de données insérées et qui apparaissent vident?
La seule hypothèse que je vois, c'est qu'il y a une double insertion dans la BDD. Et lorsque la donnée vide est supprimée, c'est la données complète qui apparaît.
Mais ça il faudrait le vérifier dans la log des requêtes SQL exécutées.
Mais la suppression devrait supprimer le commentaire, la réapparition n'est elle-même pas possible, ce n'est pas magique non plus.
Il y a moyen d'avoir un exemple de données insérées et qui apparaissent vident?
La seule hypothèse que je vois, c'est qu'il y a une double insertion dans la BDD. Et lorsque la donnée vide est supprimée, c'est la données complète qui apparaît.
Mais ça il faudrait le vérifier dans la log des requêtes SQL exécutées.
Tu as l'air de t'y connaître mieux que moi. Mais où sont les logs SQL dans le panneau d'administration ? :\
Donc ce seraient des doublons qui seraient publiés et qui se télescoperaient dans la base de données...? Comment faire pour éviter ce genre de bugs? Un "DISTINCT"? Mais ça marche avec INSERT INTO ?! ;P
Pour l'heure, je constate que ça le fait dans 9 cas sur 10. Je vais encore vérifier mes PHP mais j'ignore si ça vient vraiment de là. Veux-tu que je publie les morceaux de code? J'ai peur de mettre mon site sur un forum public, car il est encore en test Bêta xD
Donc ce seraient des doublons qui seraient publiés et qui se télescoperaient dans la base de données...? Comment faire pour éviter ce genre de bugs? Un "DISTINCT"? Mais ça marche avec INSERT INTO ?! ;P
Pour l'heure, je constate que ça le fait dans 9 cas sur 10. Je vais encore vérifier mes PHP mais j'ignore si ça vient vraiment de là. Veux-tu que je publie les morceaux de code? J'ai peur de mettre mon site sur un forum public, car il est encore en test Bêta xD
x'D dernières nouvelles, tu sais quoi? Y'a aussi des commentaires qui disparaissent en cours de route. C'est fascinant à quel point ça peut être bizarre comme bug.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Re,
j'ai consulté les tables. Et aucune valeur n'est à NULL par défaut: ça aurait pu être ça. Car si NULL est par défaut, ça aurait justifié le problème. Néanmoins, je vais commencer à croire que cela vient de mon hébergeur.
Les valeurs sont filtrées par PHP: une valeur nulle (donc vide) est normalement refusée! Donc le problème vient bien de SQL! Et je viens de voir le log SQL, déjà il est pas très intéressant (à vrai dire il n'y a que des statistiques au niveau global du serveur, et non au niveau de ma BDD) et en plus PMA est extrêmement mal configuré. La liste des problèmes détectés par PMA est immense.
Tu crois que je devrais changer d'hébergeur? Et que c'est bêtement de là que vient le problème?
j'ai consulté les tables. Et aucune valeur n'est à NULL par défaut: ça aurait pu être ça. Car si NULL est par défaut, ça aurait justifié le problème. Néanmoins, je vais commencer à croire que cela vient de mon hébergeur.
Les valeurs sont filtrées par PHP: une valeur nulle (donc vide) est normalement refusée! Donc le problème vient bien de SQL! Et je viens de voir le log SQL, déjà il est pas très intéressant (à vrai dire il n'y a que des statistiques au niveau global du serveur, et non au niveau de ma BDD) et en plus PMA est extrêmement mal configuré. La liste des problèmes détectés par PMA est immense.
Tu crois que je devrais changer d'hébergeur? Et que c'est bêtement de là que vient le problème?
Salut,
Contenu du message (codé en HTML et avec des slashs ajoutés pour éviter l'injection SQL et l'injection HTML)
Pour insérer des données en bdd, il faut oublier les fonctions tel que addslash() ou autre.
Pour éviter les injections sql, tu dois utiliser :
- mysql_real_escape_string() si tu utilises l'API MySQL (obsolète)
- mysqli_real_escape_string() si tu utilises l'API MySQLi
- les requêtes préparées ou quote() si tu utilises PDO
Il n'y a aucune raison d'échapper les caractères html avant l'insertion en bdd.
Tu dois échapper les caractères html à l'affichage des données dans ta page, avec l'utilisation de la fonction htmlentities() avec le bon encodage.
Bonne journée
Contenu du message (codé en HTML et avec des slashs ajoutés pour éviter l'injection SQL et l'injection HTML)
Pour insérer des données en bdd, il faut oublier les fonctions tel que addslash() ou autre.
Pour éviter les injections sql, tu dois utiliser :
- mysql_real_escape_string() si tu utilises l'API MySQL (obsolète)
- mysqli_real_escape_string() si tu utilises l'API MySQLi
- les requêtes préparées ou quote() si tu utilises PDO
Il n'y a aucune raison d'échapper les caractères html avant l'insertion en bdd.
Tu dois échapper les caractères html à l'affichage des données dans ta page, avec l'utilisation de la fonction htmlentities() avec le bon encodage.
Bonne journée
Fait nous voir le code de ton formulaire html !
Si tous tes champs sont pris en compte sauf un, ça peut venir d'un problème à ce niveau là !
Si tous tes champs sont pris en compte sauf un, ça peut venir d'un problème à ce niveau là !
Mdr.
Soit puisque tu le demandes volontiers xD Bref voilà le code, c'est généré via PHP, aucune erreur vu que ce formulaire fonctionne déjà, mais seulement, certaines fois, les messages apparaissent en blanc (c'est-à-dire un cas mineur, environ 9 cas sur 10 ARGLP) :
Soit puisque tu le demandes volontiers xD Bref voilà le code, c'est généré via PHP, aucune erreur vu que ce formulaire fonctionne déjà, mais seulement, certaines fois, les messages apparaissent en blanc (c'est-à-dire un cas mineur, environ 9 cas sur 10 ARGLP) :
<?php
// Extrait de code
// Si le visiteur est connecté on affiche le formulaire via PHP
if (strlen($_SESSION['login']) > 0) {
echo('<br><form method="post" action="commentaire.php">');
echo(' <textarea name="umess" id="umess" maxlength=1024>Écrire un commentaire...</textarea><br>');
echo(' <input type="submit" value="Envoyer">');
echo('</form><br>');
}
?>
Effectivement il est plutôt simple, le bug ne doit pas venir de là.
Si dans ta page commentaire.php tu affiches le $_POST, est-ce que tu le vois bien rempli à chaque fois ? Idem si tu affiches ta requête sql d'insertion ?
Ce qu'il faudrait essayer de déterminer c'est si la donnée n'est pas envoyée par le formulaire (vu ton code ça ne doit pas venir de là), et si elle l'est bien, est-ce qu'elle est insérée en bdd et perdue ensuite, ou est-ce qu'elle n'est même pas insérée.
Détails bête mais j'imagine que tu déjà vérifié que tu utilisais bien $_POST['umess'] tout le temps et que tu n'as pas une faute de frappe à un endroit ?
Sinon quand tu disais que tu as vu le contenu réapparaitre, tu veux dire dans la bdd ?
Est-ce que tu as pensé à vérifier les autres champs de ta ligne, c'était bien exactement la même ?
Si dans ta page commentaire.php tu affiches le $_POST, est-ce que tu le vois bien rempli à chaque fois ? Idem si tu affiches ta requête sql d'insertion ?
Ce qu'il faudrait essayer de déterminer c'est si la donnée n'est pas envoyée par le formulaire (vu ton code ça ne doit pas venir de là), et si elle l'est bien, est-ce qu'elle est insérée en bdd et perdue ensuite, ou est-ce qu'elle n'est même pas insérée.
Détails bête mais j'imagine que tu déjà vérifié que tu utilisais bien $_POST['umess'] tout le temps et que tu n'as pas une faute de frappe à un endroit ?
Sinon quand tu disais que tu as vu le contenu réapparaitre, tu veux dire dans la bdd ?
Est-ce que tu as pensé à vérifier les autres champs de ta ligne, c'était bien exactement la même ?
environ 9 cas sur 10
Il faudrait identifier ce qu'il y a de différents pour le cas qui ne fonctionne pas. Caractères spéciaux ?
Tu peux faire des tests et vérifier l'état de ta variable à chaque étape du traitement :
- à la récupération du message dans $_POST
- après l'échappement des caractères sql avant l'insertion en bdd
- etc..
Il faudrait identifier ce qu'il y a de différents pour le cas qui ne fonctionne pas. Caractères spéciaux ?
Tu peux faire des tests et vérifier l'état de ta variable à chaque étape du traitement :
- à la récupération du message dans $_POST
- après l'échappement des caractères sql avant l'insertion en bdd
- etc..
Ok merci les gars, je vais faire une série de tests et voir ce qui en advient. Ca doit venir des accents, une fois j'ai mis du cyrillique dans un post et rien n'est apparu. Mais le plus curieux c'est l'absence de date aussi, parfois. Cependant j'ai déjà vu un membre qui ne rencontrait jamais aucun problème avec les commentaires... Pff, à croire que c'est sélectif ;-D
Je vous tiens au jus de Ricard.
Je vous tiens au jus de Ricard.
O_o ça alors, ça vient de l'encodage...
Tous les commentaires avec des accents sont refusés! Systématiquement!
Comment remédier à ce problème sachant que je peux modifier l'encodage des attributs? Lequel mettre, parmi la liste immense qu'il y a? Ou alors, comment encoder en ISO (genre é = é) pour que ça devienne du ANSI brut?
Merci d'avance et merci de vos réponses.
Par contre ça répond pas au fait qu'un commentaire effacé réapparaisse, mais bon j'ai du mal voir après tout...
Tous les commentaires avec des accents sont refusés! Systématiquement!
Comment remédier à ce problème sachant que je peux modifier l'encodage des attributs? Lequel mettre, parmi la liste immense qu'il y a? Ou alors, comment encoder en ISO (genre é = é) pour que ça devienne du ANSI brut?
Merci d'avance et merci de vos réponses.
Par contre ça répond pas au fait qu'un commentaire effacé réapparaisse, mais bon j'ai du mal voir après tout...
Apparemment c'est un problème d'encodage dans les attributs MySQL. Mais comment convertir les messages en codes ISO ou encore faire que les tables veuillent bien accueillir des accents? Et pourquoi c'est TOUT le message qui saute, les caractères sont pas plutôt censés JUSTE bugger ?!
Vous m'avouerez que c'est un peu con...
Vous m'avouerez que c'est un peu con...
Le sgbd gère très bien les accents et l'encodage, à condition d'utiliser les bonnes méthodes.
Si ton échappement de caractère pour l'insertion en bdd est fait avec addslashes() ou de htmlentities, rien ne garanti que ta requête soit syntaxiquement correcte et donc aucune donnée n'est enregistré.
Regarde mon premier message : pour échapper les caractères spéciaux sql il faut utiliser les requêtes préparées ou mysqli_real_escape_string() selon l'api utilisé, et rien d'autre.
Ces fonctions sont les seules à connaitre les caractères spéciaux et l'encodage utilisé par le sgbd.
Si ton échappement de caractère pour l'insertion en bdd est fait avec addslashes() ou de htmlentities, rien ne garanti que ta requête soit syntaxiquement correcte et donc aucune donnée n'est enregistré.
Regarde mon premier message : pour échapper les caractères spéciaux sql il faut utiliser les requêtes préparées ou mysqli_real_escape_string() selon l'api utilisé, et rien d'autre.
Ces fonctions sont les seules à connaitre les caractères spéciaux et l'encodage utilisé par le sgbd.
