Discussion :

[alain31tl]

Salut

Il m'est arrivé ce genre de souci et celà venait d'un conflit entres variables de sessions et variables $_POST.

Je l'avoue, j'ai lu cette file un peu en diagonale , mais vu le titre et le fait que des variables passées en $_POST depuis un formulaire, est ce qui a retenu mon attention.

Bref, je ne connais pas le contenu de tes scripts mais je serais curieux de savoir comment sont déclarées tes variables de sessions, et parrallélement ce que tu envoies en $_POST depuis ton formulaire.

En d'autres termes, est-ce l'une de tes variables $_POST a le même nom que l'une de tes variables de session ?

C'est peut-être une piste à explorer.

[boteha]

Bonjour,

Merci de ta réponse.

En d'autres termes, est-ce l'une de tes variables $_POST a le même nom que l'une de tes variables de session ?

Je vais vérifer, mais ça n'étonnerait.

Afin de prévenir ce problème, toutes les variables de SESSION ont un nom qui se termine par "ses".

En plus, tu as lu en diagonable, mais le problème est occasionnel et ne peut pas être reproduit...

Par ailleurs, les scripts sont prévus pour accepter registar_globals à on ou off sur le serveur.

Je me demande si ce n'est pas le navigateur client qui détecte un (faux) problème de sécurité et refuse de transmettre $_POST...

[alain31tl]

...Je vais vérifer, mais ça n'étonnerait...

Bonjour
Oui, cela ne mange pas de pain.
Les variables transmises via la méthode POST sont transmises vers le navigateur qui les exploitent.
Dans ce cas de figure, je ne vois pourquoi (sauf erreur de script) elle ne serait pas reconnue dans cette phase.(??)
Je ne connais aucun navigateur incapable de traiter du php.
Les variables de sessions sont exploitées par le serveur et transmises vers le navigateur, qui les exploitent donc aussi.
Si 2 variables sont identiques ( POST + Session), le système ne comprend plus trop et risque d'écraser l'un d'entre elle. Et prioritairement, il va privilégier et conserver celle mise en session.

Si ce n'est pas le cas (doublon), faudra éliminer cette hypothèse et chercher ailleurs.

[boteha]

Bonjour,

Merci de ta réponse, je vais vérifier les noms des variables, comme ça on pourra éliminer définitivement cette piste.

Je te tiens au courant au plus tôt.

[boteha]

Bonjour,

je vais vérifier les noms des variables, comme ça on pourra éliminer définitivement cette piste.

Bon, voilà, j'ai vérifié et je certifie que les noms sont tous différents sans confusion possible.

Je pense que le bug occasionnel de perte de $_POST provient du navigateur client ou du serveur.

Il n'est sans doute pas possible de corriger la survenance de ce bug qui de toute façon est très rare.

La question intéressante est de savoir s'il y a moyen de faire quelque chose pour le navigateur qui a perdu $_POST, de façon à ce que le client puisse réussir le prochain ajout au panier sans avoir à changer de navigateur.

[alain31tl]

Salut

....Je pense que le bug occasionnel de perte de $_POST provient du navigateur client ou du serveur.....

Non, pas du serveur, les variables transmises par GET ou POST ne sont pas collectées, ni enregistrées sur le serveur.
Seules les variables de session le sont, tant que la connexion est active.
Ceci dit, rien n'empêche de sauvegarder une variable POST en variable de session, pour exploitation ultérieure.
Mais pour cela, encore faut-il que le navigateur l'ai bien interceptée et il devrait le faire sans souci si il n'y a pas d'erreur de script qui se balade
dans les sources.
Donc, en POST classique, exclure le serveur.

Perso, je n'ai jamais eu de souci de transmission de variables POST ou GET.
Pour cette raison aussi que je reste persuadé que le navigateur est hors de cause.
Je pencherais plus pour un conflit dans le script chargé d'envoyer ou de récupérer cette variable ou d'une étrangeté de la part de l'utilisateur.

Une idée pourtant, serait de tester d'envoyer au navigateur cette même variable POST...mais en doublette.
En pratique, ton formulaire envoie "ta_variable" depuis un input, ou autre...normal.
Mais rien ne t'empêche de renvoyer en doublon, cette même variable en type hidden, ex :

Code :

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

1
2
3
4
5
<?php
print("
<input type=\"hidden\" name=\"nom_de_ta_variable\" value=\"$ta_variable\">
");
?>

Ligne que tu intégres dans ton formulaire.

Dans ce cas, si ton navigateur ne l'intercepte pas non plus, c'est qu'il met vraiment de la mauvaise volonté le bonhomme.

Dernière hypothése, puisque le bug ne se manifeste que trés rarement :
La communication n'est pas compliquée, c'est ton formulaire qui envoie les variables au navigateur.
Soit ton formulaire ne fait pas son job, soit le navigateur ne pige pas de temps à autre. Tiens donc !
Et si, ni l'un, ni l'autre ne sont responsables du "hic"...reste finalement l'utilisateur client.

Ah tiens ! c'est nouveau ce truc là.
Si l'utilisateur n'envoie rien, POST est vide.
Si l'utilisateur balance des caractéres spéciaux, peut-être que le navigateur ne va pas apprécier.

Ok, je suppute, mais il faut bien procéder par élimination des causes probables.

Edit :
PS : Le titre est erroné . Une variable transmise par POST n'est pas une variable de session.

[boteha]

Merci de ta réponse

Si l'utilisateur n'envoie rien, POST est vide.
Si l'utilisateur balance des caractéres spéciaux, peut-être que le navigateur ne va pas apprécier.

J'ai vu le bug une fois chez un ami et le comportement de l'utilisateur était normal.

Je répète encore une fois la manifestation de ce bug rarissime et impossible à reproduire :

Le client fait un ajout au panier
Empty ($_Post) —> Message d'excuse
Il réessaye
Même punition
Il réessaye
Même punition

Il change de navigateur
Ça marche

Il reprend le lendemain le navigateur récalcitrant
Cette fois ça marche...

Voilà où on en est...

PS : Le titre est erroné . Une variable transmise par POST n'est pas une variable de session.

Tu as raison, mais au départ je pensais que le test portait sur le panier qui est une variable de SESSION.
Le test initial porte sur $_POST et ça là que ça bloque.

Je me demande si ce n'est pas le navigateur qui invente un problème de sécurité.

[alain31tl]

Je me demande si ce n'est pas le navigateur qui invente un problème de sécurité.

Possible, et encore sous réserve, en tout cas ce serait bien la première fois que j'entends parler d'un conflit de navigateur avec des variables émises avec la méthode POST.

Quand je dis "possible", c'est après avoir écarté toutes les causes possibles vues en amont.

Sinon, tu peux toujours utiliser (en test) la méthode hidden, pour forcer le navigateur à bien prendre en compte la variable.
Mieux vaut 2 fois qu'une, et de plus, cela ne pose aucun problème de sécurité.

Une dernière piste, 2 navigateurs connectés (même utilisateur) sur un même site peut causer des problèmes de retour de variables de session cette fois.
Si tu modifies depuis un navigateur une variable de session (quantité par exemple), elle ne sera jamais interprétée en temps réel sur le second navigateur.

[boteha]

Encore merci de tes réponses,

Une dernière piste, 2 navigateurs connectés (même utilisateur) sur un même site peut causer des problèmes de retour de variables de session cette fois.

Non, ce n'est pas cette situation.

Sinon, tu peux toujours utiliser (en test) la méthode hidden, pour forcer le navigateur à bien prendre en compte la variable.
Mieux vaut 2 fois qu'une, et de plus, cela ne pose aucun problème de sécurité.

Alourdir le système pour un bug rarissime, sans même savoir si ça va marcher car tu ne peux pas tester, je ne suis pas trop partant.

En plus, vu que tout $_POST est perdu, le hidden serait perdu aussi, non ?

Je ne sais pas comment fonctionne les navigateurs, mais n'y a-t-il pas moyen d'essayer quelque chose ?

[alain31tl]

Il ne s'agit pas d'alourdir la source. C'est juste une ligne a rajouter dans le formulaire.
J'ai des scripts qui font plus de 400 lignes et ca ne pénalise pas le traitement.
De toute façon, sans test, tu ne pourras pas juger dans le temps.

Maintenant, tu peux toujours renvoyer ton formulaire vers une page vierge pour vérifier si à chaque fois ta variable s'affiche mais ca ne t'avancera pas plus.
Si à un moment donné, elle ne s'affiche plus, tu n'en connaitras tjrs pas les raisons.
Franchement, je ne vois pas d'autres solutions immédiates, surtout sans codes sources.

[boteha]

Bonjour,

Encore merci.

C'est juste une ligne a rajouter dans le formulaire.

D'accord, mais c'est le test :

Empty ($_POST)

qui bloque.

Donc, ajouter un hidden ne sert à rien.

À mon avis, il faut faire quelque chose en direction du navigateur client.

[alain31tl]

.........Empty ($_POST)........

Salut

On peut voir comment est composée ta condition complète ci-dessus ?

[boteha]

Re-bonjour,

On peut voir comment est composée ta condition complète ci-dessus ?

Simple :

Code :

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

1
2
3
4
5
6
7
 
if (Empty ($_POST))
{
Appelle la fonction qui renvoie à l'accueil avec un message d'erreur'
 
exit;
}

[alain31tl]

C'est simple, en effet.

Je composerais ainsi perso :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
if (empty($_POST) && empty($_POST['ta_variable']))
{
Appelle la fonction qui renvoie à l'accueil avec un message d'erreur'
 
exit;
}
else
{
extract($_POST);
...suite de ce que tu veux faire des variables...
}

[boteha]

Bonsoir,

Merci de ta suggestion, mais je ne vois à quoi cela sert d'ajouter :

Code :

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

1
2
 
&& Empty ($_POST['ma_variable'])

Si Empty ($_POST) == TRUE, alors Empty ($_POST['ma_variable']) est forcément TRUE.

Si une grosse boîte est vide, la petite boîte à l'intérieur de la grosse boîte n'existe pas, tu n'as pas besoin de demander si elle est vide.

D'accord ?

Quelqu'un a conseillé de tester avec !isSet plutôt qu'avec Empty, mais il est clair que Empty est plus juste.

[alain31tl]

Mieux vaut une condition dans l'esprit de php que de faire du rudimentaire.
Enfin, c'est dans ma philosophie.

Allez, c'est bon, j'ai assez donné dans cette file.
Bonne chance avec tes méthodes.

[OPi]

Quelques petites remarques probablement sans incidence...

L'ajout au panier se fait par un formulaire method="POST" et $_POST est testé en premier.

Il faut écrire method="post" et pas method="POST".

Pour les form, mes balises sont bien fermées, je ne pense pas que le problème puisse venir de là

J'ai vu des form contenant directement des éléments qui devraient être inclus dans un div (ou p, fieldset...)

J'ai vu ceci dans une page :

Code :

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

1
2
3
<li id="tet">T&ecirc;tes de chapitre <i>||</i> <a href="s.php?a=J3J9,J3AL&amp;c=don)&amp;r=" class="pp">Nouvelle recherche</a></li>
...
<tr><th id="tet">Pi&egrave;ces</th><th></th><th></th><th>Prix&nbsp;TTC</th></tr>

Deux fois le même id !

Je le répète tout ceci est probablement sans importance, mais cela donne du code XHTML incorrect. Cela n'apparaît pas lorsque l'on clique sur l'image qui renvoie vers le validateur du W3C mais je suppose que c'est parce que celui reçoit une page différente puisqu'il est dans un contexte différent. Je recommande chaudement le plugin suivant pour Firefox : HTML Validator.

[boteha]

Bonjour,

MERCI de tes réponses.

Je vais regarder tout cela et corriger.

Pour ta remarque sur les form :

J'ai vu des form contenant directement des éléments qui devraient être inclus dans un div (ou p, fieldset...)

form est de type block
Je me demande toujours pourquoi il faut ajouter encore un div (ou p, fieldset...).
Je ne vois pas trop la logique et j'oublie...

[boteha]

Bonjour,

Il faut écrire method="post" et pas method="POST".

D'accord, mais c'est bon sur le site, il n'y a que dans ce post que j'ai écrit POST.

J'ai vu ceci dans une page :
Code :
<li id="tet">T&ecirc;tes de chapitre <i>||</i> <a href="s.php?a=J3J9,J3AL&amp;c=don)&amp;r=" class="pp">Nouvelle recherche</a></li>
...
<tr><th id="tet">Pi&egrave;ces</th><th></th><th></th><th>Prix&nbsp;TTC</th></tr>

Corrigé, merci.

J'ai vu des form contenant directement des éléments qui devraient être inclus dans un div (ou p, fieldset...)

Je suppose que cela concerne les SELECT de la page de recherche.
J'ai donc ajouté un balise p à l'intérieur des form qui eux mêmes sont dans des cellules.

Code :

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

1
2
3
4
5
6
7
8
 
<td><form method="get" action="h.php">
<p><select name="ssg[B1]">
<option value="tou" selected="selected">71 produits</option>
...
<option value="*rpi">Rallonge USB active</option>
</select><input type="submit" value="&lt; Affiner" /></p>
</form></td>

C'est fait juste sur le site de développement, j'attends de tester pour basculer en production.

Autrement, j'utilise le navigateur Icab sur Mac qui a un debogueur html intégré mais il ne signale pas ces erreurs.

Encore merci.

[b.jomaa]

Bonjour,

Par analyse des choses ce problème (même s’il n'est pas très fréquent) ne peut pas être du coté client (cookie, navigateur,...) ni de coté serveur (session,...) mais l'axe d'étude dois être simplement les données eux même puisque en parle d'un formulaire et d'un post.

Dans votre cas et pour générer ce problème il suffit d'avoir un

<input type="radio" name="super" value="X" />

dont X une chaine de caractère qui contient un Apostrophe par exemple :

<input type="radio" name="super" value="F8N011e'aBLU" />

Il arrive des fois que dans la page suivante on récupère que F8N011e comme résultat et donc ce code produit n'existe pas on ne peut pas l'ajouté au caddy !!!

On change le navigateur ou bien aussi on ferme le même navigateur et on le re-ouvre par magie çà fonctionne et on récupère le bon produit dans le caddy car cette fois ci le post a envoyé F8N011e/'aBLU ce qui donne dans la requête SQL le code produit F8N011e'aBLU


Je pense donc la 1ere étape une requête select sur les codes que vous utilisez dynamiquement dans la value de bouton radio et voir s'il y a des codes qui contient le caractère Apostrophe