J'ai un petit problème avec un vieux site que je remets à jour. En fait, il contient de vieilles commandes de la forme "mysql_" et donc je suis en train de les remplacer par des commandes PDO.
Donc en général je remplace les :
mysql_connect par $bdd = new PDO(...)
mysql_query par $bdd->query(...)
mysql_real_escape_string par $bdd->quote(...)
mysql_fetch_array par $bdd->fetch()
mysql_close() par $bdd=NULL
Or voilà, j'ai déjà effectué ces remplacements maintes fois sans avoir de problème mais là lorsque je veux ouvrir une page (qui se sert du fichier authentification.php), j'ai le message d'erreur suivant :
Notice: Array to string conversion in D:\wamp\www\vanadium\commun_shop\utils\authentification.php on line 18
Je ne comprend pas d'où vient le problème et j'ai besoin de votre aide. Je vous en remercie d'avance. Voici le code du fichier :
<?php //Démarrage de la session
session_start();
?>
<?php //Processus d'authentification
//Vérification de l'existance et de la non-nullité des variables
if (isset($_POST['identifiant']) AND isset($_POST['mdp']) AND $_POST['identifiant'] != NULL AND $_POST['mdp'] != NULL)
{//Les variables sont bien, on continue
//Connexion à la BDD
$bdd=new PDO("mysql:host=localhost;dbname=vanadium", "shop", "bb38f22jmtJQQZGG");
$bdd->query("SET NAMES 'UTF8'");
//On check si les entrées ne contienne pas d'injection SQL ou de code html
$identifiant = $bdd->quote(htmlspecialchars($_POST['identifiant']));
$mdp = $bdd->quote(htmlspecialchars($_POST['mdp']));
//Lecture du hash dans la BDD
$retour_hash_bdd = $bdd->query("SELECT hash_pw FROM shop WHERE id_shop='$identifiant'") or die($bdd->errorInfo()) ;
//Fermeture de la connexion
$bdd=NULL;
//Traitement de ce qui sort de la BDD
$hash_bdd = $retour_hash_bdd->fetch();
//Convertion du mdp en hash
$hash = sha1($mdp);
//Comparaison des hash
if ($hash == $hash_bdd['hash_pw'])
{//Si les deux hash coincident : mot de passe bon -> Creation de l'identifiant de session
$_SESSION['id_shop_connecte'] = $identifiant ;
session_write_close();
//Redirection vers la page d'où vient le client
$origine = $_SERVER['HTTP_REFERER'];
echo "<meta http-equiv='refresh' content='0;url=$origine' />";
}
else
{//Si les deux hash ne correspondent pas : mot de passe faux
echo "<meta http-equiv='refresh' content='0;url=../../$identifiant/connexion.php?erreur_idmdp=true' />";
}
}
else
{//Tout les champs n'ont pas été rempli
$identifiant = $_POST['identifiant'];
echo "<meta http-equiv='refresh' content='0;url=../../$identifiant/connexion.php?erreur_champs=true' />";
}
session_write_close();
?>
Salut !
Vérifie si tes différentes variables avant même la ligne 18 contiennent bien ce à quoi tu t'attends. Je trouverais étrange que le problème soit réellement à la ligne mentionnée, du fait que la ligne 14 ne retourne bel et bien qu'une chaîne de caractères, avec l'utilisation d'une fonction qui fait mal aux yeux : on ne se sert pas de htmlspecialchars() ni de htmlentities() sur des valeurs qu'on va utiliser dans des requêtes. Cette fonction n'est pas pour "sécuriser" des valeurs pour une utilisation dans du SQL (risque d'injection SQL), mais pour sécuriser des chaînes à l'affichage dans du HTML (faille XSS).
Autre chose : la ligne 11 n'est pas à effectuer ainsi : il faut ajouter ;charset=utf8 à la fin du premier paramètre du constructeur de PDO et supprimer cette ligne qui devient inutile.
Au moins, j'assume plus que simplement mettre des -1
Et je tente d'aider l'auteur du sujet, pas simplement de donner un avis sur la manière dont l'aide est apportée.
Arriverais-tu à éclairer la lanterne du pauvre aveugle incompétent que je suis et m'expliquer le lien entre ce que tu me fais lire et le souci de l'auteur, s'il te plaît ?
Tu proposes l'utilisations de fonctions à l'auteur alors que tu ne les maîtrise pas ! Va te documenter et apprendre le PHP avant de conseiller les gens. Merci !
Allez, fais un message de plus de trois phrases et crache le morceau !
Edit
Ah, et au passage, pourquoi ne me corriges-tu pas, vu que tu dis que je raconte n'importe quoi ? Ce serait un tant soit peu plus constructif, je pense…
Pour les injections SQL utilises plutot les requetes préparées, c'est dommage d'utiliser PDO et de "mal" l'utiliser.
Regarde du coté de http://fr2.php.net/manual/fr/pdostatement.bindvalue.php
Sinon, n'utilises pas de die(), utilises plutot les exceptions. Là s'il y a une erreur tu vas afficher à l'écran des infos sur la bdd, ce que les pirates adorent. Gére les erreurs dans des fichiers de logs.
Tiens nous au courant si on utilisant bindValue et prepares, si tu as toujours le soucis.
Non, du tout, mais je trouve que toi tu as mal lu mon message. Je parlais bien de ne pas utiliser ces fonctions sur des valeurs qu'on va utiliser dans des requêtes. Donc je ne comprends toujours pas ton accès de… De quoi, au fait ?
>+1 pour Appo qui lui s'y connait bien et a raison !
Il faut utiliser les requetes préparées
Il est conseillé d'utilisé prepare mais ce n'estp as une nécessité. Sans compter que mal utilisée elles sont aussi peu sécurisée que les autres.
Enfin, non, il ne faut pas utiliser htmlspecialchars quand on insère en bdd. C'est Ymox qui a raison sur toute la ligne. Va apprendre le PHP coco.
Eh bien, j'ai vraiment peur pour toi parce que tu as tort. Le propos d'Ymox est vrai, il a pleinement raison dans le fait qu'il ne faut PAS utiliser ces fonctions sur des valeurs qu'on va utiliser dans des requêtes.
En effet, ce n'est pas obligé mais quand meme très très fortement conseillé, d'ailleurs la doc php le dit elle meme
"Si vous utilisez cette fonction pour construire des requêtes SQL, vous êtes vivement invités à utiliser PDO::prepare() pour préparer les requêtes SQL avec des paramètres liés au lieu d'utiliser PDO::quote() pour interpréter les entrées utilisateur dans la requête SQL. Les requêtes préparées avec des paramètres liés sont non seulement plus portables, plus souples et plus sécuritaires, mais bien plus rapides à exécuter que d'interpréter les requêtes, étant donné que les côtés client et serveur peuvent mettre en cache une version compilée de la requête."
Eh bien, j'ai vraiment peur pour toi parce que tu as tort. Le propos d'Ymox est vrai, il a pleinement raison dans le fait qu'il ne faut PAS utiliser ces fonctions sur des valeurs qu'on va utiliser dans des requêtes.
Je gère un site avec 10K de visiteurs unique par jours pas pas besoin d'avoir peur pour moi. Mais je t'en remercie, c'est ce que font les débutantes.
L'utilisation de htmlspecials est conseillé, même pour l'insertion de contenue dans une bdd ! As tu une preuve que ca ne l'est pas avant de dire qui a raison ?
Et en effet, on n'utilise pas les fonctions htmlspecialchars et htmlentities dans ce cas. La fonction quote() s'occupe déjà de protéger la chaine. En gros c'est l'équivalent du mysqli_real_escape_string
>Je gère un site avec 10K de visiteurs unique par jours pas pas besoin d'avoir peur pour moi. Mais je t'en remercie, c'est ce que font les débutantes.
L'utilisation de htmlspecials est conseillé, même pour l'insertion de contenue dans une bdd ! As tu une preuve que ca ne l'est pas avant de dire qui a raison ?
Oui, j'en ai une : essaie de faire une API pour mobile qui fonctionne une fois que tu as pourri ta bdd avec des htmlspecialchars. Une petite démo ici
Hé coco, quand tu bosses vers la DB, t'es pas en sortie mais en entrée. C'est ce qu'on appelle une insertion. Marre de ceux qui ne savent pas de quoi ils parlent...
Non, il ne faut pas mettre de htmlspecialchars dans ta bdd. regarde la vidéo, il y a au moins deux arguements qui peuvent s'avérer rapidement importants qui y sont développés.
Premier argument : cela empêche de faire évoluer ton application web en la rendant dispo mobile
Deuxième argument : cela crée des incohérence dans les fonctions de tri, de remplacement... et donc possiblement dans les index.
>Hé coco, quand tu bosses vers la DB, t'es pas en sortie mais en entrée.
La db est une sortie de ton application quand tu insères des choses et une entrée de l'application quand tu fetch des choses.
La db est une sortie de ton application quand tu insères des choses et une entrée de l'application quand tu fetch des choses.
Oui, de ce point de vue. Mais je me place par rapport à la base de donnée où une insertion est toujours une entrée, la sortie étant le résultat affiché après le traitement d'une requête donnée.
La db est une sortie de ton application quand tu insères des choses et une entrée de l'application quand tu fetch des choses.
Oui, de ce point de vue. Mais je me place par rapport à la base de donnée où une insertion est toujours une entrée, la sortie étant le résultat affiché après le traitement d'une requête donnée.
MDR aller tu justifie pas le noob tu t'es fait sévèrement corriger
Oui, de ce point de vue. Mais je me place par rapport à la base de donnée où une insertion est toujours une entrée, la sortie étant le résultat affiché après le traitement d'une requête donnée.
Oui, je comprends, mais la règle de sécurité, c'est filter input escape output. La préparation surtout méthode PDO (EMULATE_PREPARE), c'est de l'échapement, si on se place comme toi on ferai donc escape input, bizarre non?
MDR aller tu justifie pas le noob tu t'es fait sévèrement corriger <img src="/bundles/tinymce/vendor/tiny_mce/plugins/emotions/img/rire.gif" title=":lol:" alt=":lol:" />
Pour l'instant, le noob troll crétin... c'est toi.
Sauf que ce n'est pas une erreur. Juste deux référents différents: par rapport à l'application, et par rapport à la base de données. Après la seule vraiment valide est la sienne. Le référent doit toujours être l'application.
Tu peux désormais aller sur ton profil, onglet paramètres, descendre la page et cliquer sur le lien puis valider.
Des tutos surtout et gratuit|Déboguez php|Un cours sur ASP.NET MVC
Des tutos surtout et gratuit|Déboguez php|Un cours sur ASP.NET MVC
Des tutos surtout et gratuit|Déboguez php|Un cours sur ASP.NET MVC
Des tutos surtout et gratuit|Déboguez php|Un cours sur ASP.NET MVC