Pour la qualité du soft, cela ne veut rien dire
Il suffit de faire un bon soft et d'ajouter une ligne dans le texte de sortie: tu auras beau corriger toutes les failles, la ligne restera (mais je médit un peu là, donc bon).
Au niveau du code en général:
Il suffit de faire un bon soft et d'ajouter une ligne dans le texte de sortie: tu auras beau corriger toutes les failles, la ligne restera (mais je médit un peu là, donc bon).
- Il n'est pas certain que getIp() renvoie bien une IP. Il faudrait vérifier avec la doc de $_SERVER. (x2, $ip est utilisée deux fois dans deux requêtes)
Au niveau du code en général:
- Je ne comprends pas le fait de tester le MAX(id)... Si tu veux savoir si l'article existe, teste directement:
Et un num_rows te répondra directement si oui ou non l'article existe (Aparté: le "LIMIT 1" optimise-t-il la requête? C'est à dire que si idArticle est une clef primaire ou unique, savez-vous si MySQL est assez futé pour s'arrêter dès le 1er résultat trouvé au lieu de continuer la recherche?)Code :SELECT 1 FROM table WHERE idArticle=$id LIMIT 1
- $idArticle (ou similaire) étant un entier, inutile de l'entourer de guillemets dans tes requêtes (cela allège un peu l'écriture); de plus, comme tu utilises des guillemets double autour de la requête, tu n'es pas forcé de faire "SELECT...".$idArticle."..." un simple "SELECT ... $idArticle..." suffit car PHP fera le remplacement nécessaire (sinon, utilises des apostrophes ' au lieu des guillemets doubles " si tu tiens à isoler la variable du texte de la requête)
- A plusieurs endroits, tu fais deux requêtes, type "je fais une requête pour récupérer une ligne, je teste si la ligne existe, je fais une nouvelle requête pour lire les données". Mauvaise habitude pour deux raisons: 1) imagine que la ligne "fiche le camp" entre temps, car l'utilisateur a cliqué deux fois très vite sur le bouton de vote, alors le teste sera valide, mais la seconde requête pourrait ne pas marcher 2) Ce n'est pas optimisé.
Ne fais qu'une seule requête pour récupérer les données, et ensuite si ces données existe, traite-les.
- Se baser sur l'IP n'est pas terriblement fiable, tu auras peut-être des "faux" votes (des gens qui changent d'IP et revotent) ou des blocages si deux personnes ont la même IP (se baser sur l'IP est déconseillé au niveau d'un site car c'est plus du ressort du réseau que du site). Je n'ai pas de solution miracle à proposer.
- Echappe les noms de colonne et de tables avec `` (alt+gr & touche 7), comme "SELECT `id`FROM `table` WHERE `id`=$id"; ce sera un peu plus lisible, et cela autorisera l'utilisation d'espaces en noms de colonne (bon, c'est pas obligé, mais je trouve personnellement cela plus clair car les noms de colonnes et de table ressortent immédiatement)
- La redirection avec <script>window.location=...;</script> est ignoble... La méthode que je conseillerai est plutôt l'utilisation des headers HTTP, dont le code HTTP 302. Là, ton script est un peu mélasseux: il gère les trucs (partie controlleur) comme l'enregistrement du vote, et en même temps, il gère l'affichage (echo())... Sépare les deux: contrôleur d'abord, et ensuite l'afficheur, quitte à faire cela "simplement" en créant un buffer intermédiaire: au lieu d'envoyer directement au navigateur, envoie les données à un buffer (soit une chaîne texte, soit avec une fonction perso type echoBuffer, soit avec ce que la documentation php peut te proposer car je crois que cela existe déjà). Ainsi, tu séparera clairement les deux, et tu pourras utiliser facilement la fonction header() pour définir des cookies, ou rediriger le client