j'ai toujours NULL

En fait a priori dans ma partie INSERT ca focntionne bien :

		// Insertion du nouvel utilisateur & cryptage de $mdp
		$sql = "INSERT INTO gesten_utilisateur(ID_UTILISATEUR, NOM, PRENOM, PSEUDO, MOT_DE_PASSE, MAIL) VALUES('','$nom','$prenom','$login_aj', AES_ENCRYPT('. $mdp_aj .', '. $cle .'), '$mail')";
		mysql_query($sql) or die('Impossible d\'inserer les valeurs dans la table notes');

dans la partie UPDATE aussi :

// Requete pour la modification & cryptage de $mdp_aj
$sql .= "UPDATE gesten_utilisateur 
SET NOM='$nom', PRENOM='$prenom', PSEUDO='$login_aj', MOT_DE_PASSE= AES_ENCRYPT('. $mdp_aj .', '. $cle .'), MAIL='$mail' WHERE ID_UTILISATEUR= $id_utilisateur ";
$req = mysql_query($sql) or die('Impossible de modifier l\'utilisateur'); 

Par contre dans la partie SELECT avec DECRYPT c'est pas bon, quand je cré un nouvel utilisateur via un formulaire il crypte bien, l'utilisateur a le droit de rentrer mais je me suis rendu compte qu'en fait n'importe quel mot de passe etait validé comme bon si il reconnait le pseudo. ou alors le pseudo reste en mémoire.

// Si tout est bon
$sql = "SELECT ID_UTILISATEUR, NOM, PRENOM, PSEUDO, AES_DECRYPT('". $mdp ."', '". $cle ."') AS MOT_DE_PASSE, MAIL FROM gesten_utilisateur WHERE PSEUDO = '".$pseudo."'";
echo $sql;
$req = mysql_query($sql) or die('Impossible de séléctionner les données dans la table users');

Ma requete dans phpmyadmin ne de donne que NULL avec le SELECT

voila je pense avoir tout expliqué

Je viens de tester une requete INSERT directement dans phpmyadmin :

INSERT INTO gesten_utilisateur(ID_UTILISATEUR, NOM, PRENOM, PSEUDO, MOT_DE_PASSE, MAIL) VALUES('','nom','prenom','login_aj', AES_ENCRYPT('test', 'kakalouette') ,'[email protected]')

J'ai fait la même chose par le formulaire d'ajout :

		$sql = "INSERT INTO gesten_utilisateur(ID_UTILISATEUR, NOM, PRENOM, PSEUDO, MOT_DE_PASSE, MAIL) VALUES('','$nom','$prenom','$login_aj', AES_ENCRYPT('. $mdp_aj .', '. $cle .') ,'$mail')";
		mysql_query($sql) or die('Impossible d\'inserer les valeurs dans la table notes');

Je précise que la cle est : kakalouette
et le mot de passe est : test

voila respectivement les résultat de cryptage :

1. B????????Gn-
2. Á¢ÅEpi?™¾

Maintenant si je verifie la premiere requete dans phpmyadmin avec :

SELECT ID_UTILISATEUR, NOM, PRENOM, PSEUDO, AES_DECRYPT('test', 'kakalouette') AS MOT_DE_PASSE, MAIL FROM gesten_utilisateur WHERE PSEUDO = 'login_aj'

La valeur retournépour MOT_DE_PASSE est NULL

idem pour la deuxième requete. (dans phpmyadmin)

Donc quand je m'hautentifie il regarde que le pseudo et pas le mdp, donc si je met un pseudo existant et un mot de passe "bidon" il me laisse rentrer.

Cela pourait il provenir de la structure de la table ? ou du code php ? je vois pas la

Si ca peux aider, merci

a priori je dirai que c'est normal qu'il ne regarde pas le contenu du mot de passe puisque tu ne lui demande pas

... WHERE PSEUDO = 'login_aj'

pas de test sur le mot de passe !!

essaie comme ceci:

... WHERE PSEUDO = 'login_aj' AND MOT_DE_PASSE=AES_DECRYPT('test', 'kakalouette')

Ha oui c'est vrai ! ben la ca verfie mais ca va pas plus loin;

Attention, ne fais pas ta vérification à l'envers:

1. Soit tu vérifie en encryptant une variable provenant de l'exétieur et tu compares la variable cryptée avec la valeur qui est cryptée dans la base;
2. Soit tu vérifie en décryptant la valeur de la base en comparant avec la variable php en clair;

La première solution sera beaucoup plus rapide puisqu'on a pas besoin de décrypter chaque valeur contenue dans la base pour la comparaison.

Tu n'as besoin en fait que deux possibilités: soit pour une vérification lors de l'identification d'un internaute, ou bien de renvoyer son mot de passe à un internaute qui a perdu le sien. Dans le premier cas, Tu n'as pas besoin de décrypter, utilise l'encryption pour la variable contenant le mot de passe saisis dans le formulaire d'identification. Dans le second cas, alors effectivement, tu dois décrypter le mot de passe contenu dans la base.

Il semble que c'est cette partie que tu as des difficultés à mettre en oeuvre.

Quand tu fais afficher la requête, est-ce qu'elle est normale ? Est-ce que la clé est bonne, est-ce que le mot de passe est bon par rapport à ce que tu attends. Compares avec la récupération brute sans décryptage de ce que tu as dans la base.

D'accord je comprend un peu mieux ce qui ne va pas.

En fait c'est juste sur ma page login.php que j'ai un problème j'ai testé la comparaison d'un mdp utilisateur ecrit en dur et j'obtient bien ce que je veux. en fait la j'essaye de comparer ce que j'avais du formulaire a la volé avec un mot de passe déjà crypté.

Donc pour continuer dans ce raisonnemnt je dois d'abord :

* rcuperer $mdp par $_POST['mdp'] (ex: test)
* crypter $mdp avec AES_DECRYPT('". $mdp ."', '". $cle ."')
* faire ma requete normale avec : WHERE PSEUDO = '".$pseudo."' AND MOT_DE_PASSE = '".$mdp_crypt."'

ce qui revient a conparer 2 mot de passe crypté

a la rigueur dans cette page je n'ai pas besoin de décrypter. je pourrait en avoir besoin effectivement en cas de perte et de renvoie

Mon raisonement est il bon par rapport a ton post precedent ?

donc maintenant il faut que je fasse ma premiere requete qui va crypter le mdp du formulaire :

$mdp_crypt = "SELECT AES_ENCRYPT('". $mdp ."', '". $cle ."') AS MOT_DE_PASSE FROM gesten_utilisateur";

et ma requete de verification qui serait :

SELECT ID_UTILISATEUR, NOM, PRENOM, PSEUDO, MOT_DE_PASSE, MAIL FROM gesten_utilisateur WHERE PSEUDO = '".$pseudo."' AND MOT_DE_PASSE = '".$mdp_crypt."'";

Ca serait ca ?

edit : j'ai un parse error

Pourquoi le faire en deux requête quand une seule suffirait ?

<?php
$sql = "SELECT ID_UTILISATEUR, NOM, PRENOM, PSEUDO, MOT_DE_PASSE, MAIL 
        FROM gesten_utilisateur 
        WHERE PSEUDO = '". $pseudo ."' 
        AND MOT_DE_PASSE = AES_ENCRYPT('". $mdp ."', '". $cle ."')";
?>

C'est normal que si tu affiches la requête, le mot de passe soit en clair: AES_ENCRYPT, c'est du SQL, pas du PHP. Donc pour le test, tu peux en effet le faire en deux requête pour voir au juste si tu obtiens les correspondances, mais en pratiques, c'est une requête de trop. Ça doit normalement fonctionner correctement avec l'unique requête proposée.

En fait j'etais parti sur 2 requetes parcque ce que tu me propose j'avais déjà essayé mais le mot de passe dans le WHERE n'est apparement pas crypté donc il ne comprend pas.

exemple le mot de passe est : essai

ce qui ne marche pas :

$sql = "SELECT *
        FROM gesten_utilisateur
        WHERE PSEUDO = '". $pseudo ."'
        AND MOT_DE_PASSE = AES_ENCRYPT('". $mdp ."', '". $cle ."')"; 

ce qui marche enfin je croyais (ecrit en fixe) :

$sql = "SELECT *
        FROM gesten_utilisateur
        WHERE PSEUDO = '". $pseudo ."'
        AND MOT_DE_PASSE = '„6sŽcÃBàô¸bñø¤—' ";

Dans le deuxième cas le mot de passe n'est plus verifié et donc n'importe quoi passe.

Avec 2 requetes je me disais que je pourrais recuperer dans une variable le mot essai crypté que mettrais dans le WHERE pour faire la vérification. Mon résonnement n'est peux être pas logique ?

Ceci dit j'ai essayé de faire 2 requetes mais je ne parvenanit pas en fesant un echo, a afficher le mdp crypté mais la premiere solution me parait pourtant logique, il faudrait que je puisse afficher ce qu'il fait pour voir si il crypte bien

(désolé j'ai effacé par erreur, je venais de me rendre compte que je disais des bétises)

J'ai verifié et coriger pas mal de problèmes sur l'ensemble de mes pages en esperant coriger ce problème de corespondance mais rien, je me demande si ce n'est pas dans ma page login.php

J'ai toujours mon NULL dans phpmyadmin

comment faire pour voir ce qui se passe réellement ? merci

BOn, je vais faire des tests, ce n'est pas normal.

Quel est le type de champ de ta colonne mot-de-passe dans ta base ? Pour utiliser AES_ENCRYPT, il faut un type BLOB: si tu as un champ avec un autretype, il est possible que les informations aient été tronquées à l'insertion et ne sont donc logiquement pas reconnues lors de la récupération.

En faisant exactement comme ej t'ai indiqué, tout fonctionne chez moi.

le type chez moi est Varchar(30), je viens de changer pour blob du coup il m'affiche [BLOB - 16 Octets] dans ma table, c'est normal ?

je pense qu'ila une erreur aileur encore

C'est normal l'affichage, mais maintenant, vire le contenu, refais une insertion et reteste la vérification.