Discussion :

[reventlov]

Bonjour à tous !

j'ai ce script php déclenché par un appel ajax :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
require_once("../sys_config/config_generale_site.php");
require_once("../sys_fonctions/api_fonctions.php");
base_connect($serveur_mysql,$base_site_user,$base_site_passwd,$base_site_name);
 
//données récupérées
$id_thread=trim($_REQUEST['id_thread']);
 
$ok_read=false;
 
if(mysql_query("UPDATE `threads_masters` SET `r_admin`=1 WHERE `id`='".$id_thread."'")){
	$ok_read=true;
}
 
//Tableau du résultat
$resultat=array('ok_read'=>$ok_read);
 
//envoi des résultat à la page
print(json_encode($resultat));
 
mysql_close();
exit();

On est certain d'une chose c'est que les valeur que prend $id_thread existent bien dans la base et que mon appel ajax fonctionne correctement.

Mais voilà :

- la requête parfois fonctionne et parfois non (l'update de la table ne se fait pas)

- Pourtant même quand l'update ne fonctionne pas, la valeur de $ok_read retournée par ajax est bien true...

- Donc c'est ma requête qui ne passe pas malgré que la syntaxe soit ok et que la valeur $id_thread existe bien dans la base.

- Quand l'update plante pour une valeur de $id_thread, le script ensuite plantera à tout les coup pour cette valeur MAIS : si j'appelle se script avec la même valeur qui plante DEPUIS UN AUTRE NAVIGATEUR SUR UNE AUTRE MACHINE... Là ca remarche...

Donc pour x raison ma requête correcte au niveau syntaxe avec une valeur existante dans la base plante. j'ai l'impression que si ça plante une fois, mysql est en quelque sorte capable de dire "non j'ai refusé cette requête de la machine x une fois et donc je ne l'accepte plus jamais"...

je ne sais pas trop ce qui ce passe... 1 : pourquoi ca plante une première fois et 2 : si ça a planté apparament mysql s'en souvient (y'a un cache des reque^tes sous mysql ?)

C'est un peu embrouillé tout ça mais si ça parle à quelqu'un... Une aide serait la bienvenue

[Watilin]

On est certain d'une chose c'est que les valeur que prend $id_thread existent bien dans la base

Pas toujours !
Attention à ça : $_REQUEST contient à la fois des données GET et POST. Sachant que, sauf si tu prends des mesures nécessaires, le script peut être accessible comme une page web normale, imagine si j'accède à l'adresse de ton script avec ce paramètre dans l'URL :

Code URL :

Sélectionner tout - Visualiser dans une fenêtre à part

?id_thread='%20OR%20TRUE--

Je te conseille de faire un echo de la requête SQL mais sans faire le mysql_query afin de voir ce qui se passe…
Car voilà la triste vérité : ton script est vulnérable aux injections SQL. Pour s'en protéger il y a divers réflexes à avoir :

• contrôler le type de données. En l'occurence je suppose que id_thread doit être un int, donc si tu fais $id_thread = (int) trim($_REQUEST['id_thread']) tu élimines déjà les attaques utilisant les guillemets. Voir conversion en entier.
• échapper les caractères qui changent le sens de la requête (dont les guillemets) avec mysql_real_escape_string.
• Utiliser des requêtes préparées (mysqli_prepare ou PDO::prepare). Note que tu ne peux pas faire des requêtes préparées avec la lib mysql (sans « i » à la fin), mais comme cette lib est obsolète de toute façon, il est temps de migrer

- Pourtant même quand l'update ne fonctionne pas, la valeur de $ok_read retournée par ajax est bien true...

Si la valeur dans la clause WHERE ne correspond à aucune ligne de la table, l'UPDATE ne changera aucune ligne, et c'est le comportement attendu d'une telle requête. C'est donc considéré comme un succès, et mysql_query retournera true. Encore une fois je t'invite à faire un echo de la requête pour voir si elle ressemble vraiment à ce que tu penses.

Pense à utiliser l'onglet réseau de la console de ton navigateur pour t'aider.

- Quand l'update plante pour une valeur de $id_thread, le script ensuite plantera à tout les coup pour cette valeur MAIS : si j'appelle se script avec la même valeur qui plante DEPUIS UN AUTRE NAVIGATEUR SUR UNE AUTRE MACHINE... Là ca remarche...

Donc pour x raison ma requête correcte au niveau syntaxe avec une valeur existante dans la base plante. j'ai l'impression que si ça plante une fois, mysql est en quelque sorte capable de dire "non j'ai refusé cette requête de la machine x une fois et donc je ne l'accepte plus jamais"...

je ne sais pas trop ce qui ce passe... 1 : pourquoi ca plante une première fois et 2 : si ça a planté apparament mysql s'en souvient (y'a un cache des reque^tes sous mysql ?)

Pas MySQL car le dialogue HTTP se fait entre le client (Ajax) et le serveur PHP. Le serveur SQL est une entité différente ; il est en communication avec le serveur PHP mais pas avec l'extérieur. Donc s'il y a un cache quelque part, c'est probablement sur le serveur PHP (ou éventuellement un proxy), mais j'avoue que les mécanismes en jeu sont obcurs pour moi aussi.

J'ai une hypothèse : sous certaines configurations, le serveur PHP peut réutiliser une connexion SQL « encore chaude ». Peut-être que si tu fais l'essai depuis deux machines différentes mais à peu près au même moment, tu observeras cet effet « mémoire des requêtes qui plantent ».

Tu devrais faire des cross-tests avec des paramètres précis. Quelques idées :

• depuis un navigateur différent sous la même machine ;
• depuis deux sessions différentes du même navigateur (en fermant puis ré-ouvrant le navigateur) ;
• sous le même navigateur en effaçant les cookies (d'ailleurs, tu peux examiner les cookies de chaque requête dans la console) ;
• sous le même navigateur en effaçant les « préférences de site ».

[reventlov]

Pas toujours !
Attention à ça : $_REQUEST contient à la fois des données GET et POST. Sachant que, sauf si tu prends des mesures nécessaires, le script peut être accessible comme une page web normale, imagine si j'accède à l'adresse de ton script avec ce paramètre dans l'URL :

MERCII !!!! Tu m'as mis la puce à l'oreille avec ça... Effectivement $_REQUEST peut contenir des variables POST GET des ENTETES et des REFERENCES de cookies... Mais ce tableau est zarbi car si par malheur deux clés POST GET ou autre sont identique, il considère la dernière clé...

Si $_GET['toto']=1 et qu'il existe un $_POST['toto']=2 et aussi $_COOKIE['toto']=3 la valeur de $_REQUEST['toto'] serra toujours égale à 3 car $_COOKIE fusionné en dernier ($_GET, $_POST, $_COOKIE) et donc écrase les anciennes valeurs qui avaient pour clé "toto" dans les autres tableaux...

J'ai trouvé l'explication dans les cours et tutoriels PHP je crois...

Bref comme la page d'envoi de la requete ajax comportait une pagination, ce truc a créé des embrouille avec des nom de variable en get et post identiques.

J'ai appris quelque chose aujourd'hui

Pour ce qui est de la sécurité et les injections, des script sont en cours de dev pour ça. j'ai juste simplifié mes exemples de code pour rendre tout ça plus digeste.

Merci encore une fois, tu m'as retiré une épine du pied

[Watilin]

De rien !

Je savais que c'était pas génial d'utiliser $_REQUEST mais je savais pas qu'il y avait aussi les cookies dedans… C'est vraiment pas génial