Perte des variables de session

**boteha** · 21/08/2010, 15h46

Bonjour,

Sur un site marchand de moyenne importance, le panier est une variable de SESSION et cette variable n'est enregistrée dans la base SQL que lorsque le client décide de payer.

Tout ajout au panier modifie le variable en SESSION.

Par ailleurs, à chaque fois qu'il y a besoin de cette variable, celle-ci est testée (isSet) et en cas de perte un message d'excuse est envoyé au client.

De temps en temps (rarement heureusement...) il arrive que tout ajout au panier provoque ce message.
Donc, cette variable n'arrive pas à se créer.

Si le client nous appelle, nous lui demandons de changer de navigateur et le problème disparaît.

Personne ne comprend trop d'où provient le problème...

Le serveur (mutualisé) nous conseille d'enregistrer les variables de SESSION dans mysql avec la biblitohèque adéquate.
Qu'en pensez-vous ?

Plus simplement, est-ce que l'emploi d'une fonction :
session_regenerate_id
en cas de perte de la variable de panier pourrait résoudre la chose ?

Merci d'avance.

**fredd_75** · 22/08/2010, 14h05

Je n'ai pas de solutions veritablement pour cela il faudrais que je regarde le code, je peux juste emettre des hypothese et te proposer de verifier les points suivant.

Toutes les pages permettant l'enregitrement dans la variable (donc le panier) de session ont elles bien un "session_start()" en PREMIERE ligne de la page de code? surtout pas de code html avant cette ligne ....

Le fait de changer de navigateur ne resolu pas le probleme ce qui signifie une reconnexion au serveur donc on repart a zéro mais on ne resout pas le probleme de session perdu !!

Lorsqu'il perd les variable du panier l'internaute perd t-il aussi sa connexion? qui doit etre aussi en session....

Voir aussi avec les parametres du systeme linux On appelle ça l'expiration de vie de session, elle dure qu'un nombre de minutes limitées (parfois 5, parfois plus, parfois moins), c'est à dire que la variable session est détruite au bout d'un certain temps d'inactivité ... demande au administrateur de l'hebergeur la valeur de cette dureé de vie...

oui test avec le regenerate si tu veux pour voir

tiens nous au courant !!!!
Fred75

**boteha** · 22/08/2010, 14h28

Bonjour,

Merci beaucoup de ton intérêt.

Envoyé par fredd_75

Toutes les pages permettant l'enregitrement dans la variable (donc le panier) de session ont elles bien un "session_start()" en PREMIERE ligne de la page de code? surtout pas de code html avant cette ligne ....

Aucun problème de code.
Il y a des commandes tous les jours et ce problème ne revient à nos oreilles qu'une fois tous les trois mois. On peut penser que la panne est plus fréquente, mais quand même rare.

Envoyé par fredd_75

Le fait de changer de navigateur ne resolu pas le probleme ce qui signifie une reconnexion au serveur donc on repart a zéro mais on ne resout pas le probleme de session perdu !!

Changer de navigateur résout toujours le problème (je veux dire quand le client change de navigateur sur le même ordinateur). Il semble probable que le problème provient du navigateur client.

Envoyé par fredd_75

Lorsqu'il perd les variable du panier l'internaute perd t-il aussi sa connexion? qui doit etre aussi en session....

Non.
Tout marche sauf que chaque tentative d'ajout au panier provoque le même message de perte du panier.

Envoyé par fredd_75

Voir aussi avec les parametres du systeme linux On appelle ça l'expiration de vie de session, elle dure qu'un nombre de minutes limitées (parfois 5, parfois plus, parfois moins), c'est à dire que la variable session est détruite au bout d'un certain temps d'inactivité ... demande au administrateur de l'hebergeur la valeur de cette dureé de vie...

Effectivement, on a vu avec l'hébergeur.
Les variables de session étaient flinguées toutes les demi-heures
Maintenant, c'est juste une fois par jour à 4h30 du matin.

Envoyé par fredd_75

oui test avec le regenerate si tu veux pour voir

tiens nous au courant !!!!

Le problème est que ce bug est irrationnel et inexpliqué, donc impossible à reproduire....

**fredd_75** · 22/08/2010, 14h40

effectivement c'est bizarre, et on ne peut jamais résoudre un problème que l'on ne peut pas générer... lol

Je ne peux pas plus t'aider malheureusement il faudrais que je vienne caremment dans ta boite ^^

Bon courage et tiens moi au courant si tu resout..

**boteha** · 22/08/2010, 14h56

Merci de ta réponse.

Avez-vous entendu parler de navigateurs qui ne voudraient pas lire une variable de session ?

Je ne sais même pas si le navigateur est concerné par les variables de session, je suppose que non...

Si perte du panier, je vais ajouter quelques lignes pour détruire toute la session du client en cours et la régénérer comme s'il y avait une nouvelle connexion.

Je vous tiens au courant.

**fredd_75** · 22/08/2010, 15h10

non les variable de session ne sont geré que sur le serveur. Le navigateur n'a rien a voir avec la perte de variable en session.

Le mieux serais de pouvoir determiner a partir de quel morceau de code il y a perte, il doit y avoir un morceau de code qui vide la variable ou il passe dans cette boucle que dans certaine condition .... determine le chemin de passage, l'acheminement de mise en panier et tu peux mettre des fopen (invisible coté internaute ) afin de determiner ou passe cette mise en panier.

**boteha** · 22/08/2010, 17h36

Encore merci de tes suggestions.

Cependant, je suis certain que le bug ne provient pas de nos scripts PHP, car autrement il ne serait pas résolu en changeant de navigateur.
Par ailleurs, s'il y avait un défaut de logique, le bug serait sans doute plus fréquent car l'opération en cause (ajout au panier) est hyper-fréquente.

C'est un bug au niveau du serveur.
Ce qui est bizarre, c'est que le problème ne soit pas résolu par une simple déconnexion-reconnexion avec la même navigateur.
Mais je ne suis pas sûr que cela ne soit pas résolu...

Je ne sais pas du tout comment fonctionne Appache, mais vous paraît-il possible qu'un navigateur devienne ainsi "grillé" pendant un certain temps ?

**Madfrix** · 22/08/2010, 22h15

Bonjour,

peut être une sollicitation trop importante du serveur mutualisé qui fait partir rarement ton script "en vrille" ?

Peux tu côté dév, générer la création/utilisation de plusieurs milliers de paniers afin de voir si vous reproduisez le problème ?

Il existe aussi la possibilité (non négligeable) que ce soit côté client le problème, par exemple la suppression (non voulue, fausse manip, virus...) d'une partie ou tout de ses cookies ce qui entrainerait le problème que tu connais.

A combien de (dizieme ?) de pour-cents évalues tu ce problème ?

**fredd_75** · 23/08/2010, 07h46

Il n'a jamais été question de cookie (coté client et lié au navigateur ok) mais de variable de session (coté serveur)... je me trompe?

**Madfrix** · 23/08/2010, 10h27

Tu te trompes : tu fais le lien entre les sessions et un ordinateur via les bien-nommés cookies de session. Si tu supprimes ces cookies, tu casses le lien entre l'ordinateur et le serveur pour les sessions d'où ma question et mes suggestions précédentes.

Rappel

**boteha** · 23/08/2010, 12h03

Merci de vos réponses.

Envoyé par Madfrix

Bonjour,
A combien de (dizieme ?) de pour-cents évalues tu ce problème ?

Cette panne est très très rare...
Personnellement, je ne suis jamais tombé dessus.
Je l'ai vue en live chez un copain.
Un appel tous les trois mois des clients, il est sûr que c'est plus fréquent mais pas dramatique.

La piste du cookie semble intéressante, car je ne sais pas si le bug provient du navigateur, mais il dépend du navigateur puisqu'il suffit d'en changer pour résoudre le problème.

En cas de perte de la variable de session du panier, il me semble très facile de :
1) Démolir toute la session
2) Démolir et re-générer le cookie de session

Cela suffira peut-être.

Qu'en pensez-vous ?

**fredd_75** · 24/08/2010, 06h54

Envoyé par boteha

Merci de vos réponses.

En cas de perte de la variable de session du panier, il me semble très facile de :
1) Démolir toute la session
2) Démolir et re-générer le cookie de session

Cela suffira peut-être.

Qu'en pensez-vous ?

C'est ce qui se passe lorsque l'on change de navigateur. Cela ne résout pas le problème à la racine.

**boteha** · 24/08/2010, 11h52

Bonjour,

C'est ce qui se passe lorsque l'on change de navigateur. Cela ne résout pas le problème à la racine.

Je pense que le problème à la racine provient du serveur ou du navigateur client et qu'il est donc impossible à résoudre.

Il y a parfois des bugs incompréhensibles : par exemple, j'ai vu la somme de plusieurs nombres décimaux à 2 chiffres, tous bordés par round ($nbr, 2) donner un truc du genre 100.02.05, cela dans un script utilisé plusieurs centaines de fois par jour sans problème...

Si je parviens à restituer ce qui se passe quand le client change de navigateur, c'est parfait.
Le bug se produit au premier ajout dans le panier, donc le client n'a pas perdu grand chose et il peut très vite recommencer.

J'espère avoir le temps de travailler sur ce petit bout de code cette semaine, autrement ce week-end.

Je vous tiens au courant.

**boteha** · 26/08/2010, 21h54

Bonjour,

Après ré-examen du code, le message d'alerte n'est pas provoqué par l'absence d'une variable de SESSION, mais de $_POST...

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

Pensez-vous que le bug provient du navigateur client ou du serveur ?

Je rappelle que ce bug est permanent jusqu'à ce que le client change de navigateur.

Voyez-vous un moyen d'y remédier ?

Merci d'avance.

**rfufu** · 26/08/2010, 22h25

Bonjour,

Un petit retour de la part d'un mec qui bosse également dans le e-commerce, pour un gros site...

1/ Pour la gestion des sessions, tu parles de base de données.
Après expérience, c'est une bonne chose de conserver les sessions à mesure qu'elle sont utilisée, mais je ne conseil pas la base de données utilisé pour le reste de l'appli. e.g. memcache, mcache, sharedanced...
Cela permet de ne pas perdre les sessions en cas de redémarrage d'apache et de ne pas surcharger la base de données.

2/ Les variables de session sont en réalité la mise en relation entre le client et le serveur pour qu'une série de données soient dédié à ce client.
Cette vérification du client se fait d'après plusieurs critères, dont au minimum :
- 1 coockie nommé par défaut PHPSESSID. C'est une bonne idée de changer le nom par défaut (ini_set ( "session.name", "newname" );)
- le user-agent (ici un petit article pour éviter le Session Hijacking : http://phpsec.org/projects/guide/4.html)

3/ La porté des cookies (et notamment celui de session) est importante en cas de changement de sous domaine au cours de la navigation.
Par exemple, si tu veux passer de www.monsite.tld à ssl.monsite.tld sans perdre de session, la porté de tes cookies devra être sur .monsite.tld et non www.monsite.tdl en utilisant par exemple ini_set('session.cookie_domain', '.monsite.tld');

4/ Concernant ta variable $_POST, comment est-elle alimentée et comment est-elle testée ?
Si le bug se fixe lorsque le client change de navigateur, c'est que le problème ne vient pas du serveur, mais du code de l'applicatif qui doit faire mal quelque chose.

**boteha** · 27/08/2010, 12h02

Bonjour,

Merci de tes infos.

4/ Concernant ta variable $_POST, comment est-elle alimentée et comment est-elle testée ?

Le test est des plus simples :

Code :

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

1
2
3
4
5
 
if (Empty ($_POST))
{
Appelle une fonction qui envoie un message d'erreur'
}

Comment est-il alimentée, je ne comprends pas ta question, il y a un formulaire...

Si tu veux voir en vrai :

www.touslescables.com

Je répète que je pense que ce problème ne provient pas de notre code PHP, mais qu'il y a peut-être moyen de faire quelque chose pour fixer ces bugs rares mais énervants.

**rfufu** · 27/08/2010, 16h26

Alors j'ai regardé un peu le site et j'ai deux remarques à faire.

1/ tes balises de soumission portent le même nom et tu as plusieurs formulaires (et dont certains appellent le même script). Par exemple, si une balise de formulaire n'est pas bien fermée, le formulaire validé peut très bien ne pas être celui souhaité.
Et pour info, dans ce cas, le comportement n'est pas identique sur tous les navigateurs car certain navigateur corrigent eux même une partie de code dans lequel il y a des erreurs.
Je pense qu'indiquer des noms différents peut permettre un filtrage plus fin.

2/ D'autre part, ton test est très global comme tu le dis, et de plus, il faut faire attention à la fonction empty. Pour ce genre de test, je préfère !isset() car si tu as par exemple une quantité 0, tu as une valeur 0, et pourtant empty te renvérra vrai.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
<?php
$toto = 0;
if(empty($toto)){
	echo "empty dit que toto n'existe pas\n";
} else {
	echo "empty dit que toto existe\n";
}
if(!isset($toto)) {
	echo "isset dit que toto n'existe pas\n";
} else {
	echo "isset dit que toto existe, mais est peut-être null ou égal à zéro\n";
}

reverra :

Code :

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

1
2
empty dit que toto n'existe pas
isset dit que toto existe, mais est peut-être null ou égal à zéro

e.g.
A mon sens, un test de ce genre serait préférable :

Code :

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

1
2
3
4
<input type="submit" id="addToCart" name="addToCart" [...] />
if(!isset($_POST['addToCart']) {
	[...] // error handler
}

Question pour faire avancer le chmilblick:
Est-ce qu'il y a un point commun lors de l'apparition du bug ?
Sont-ils observés sur les mêmes fiches produits ou sur le même navigateur ?

J'espère avoir été assez clair dans mes explications... Ça me parait fouillis... :/

**boteha** · 27/08/2010, 17h26

Merci de tes remarques.

Est-ce qu'il y a un point commun lors de l'apparition du bug ?
Sont-ils observés sur les mêmes fiches produits ou sur le même navigateur ?

Non, justement, cela n'a rien à voir avec les produits ni avec les navigateurs.
Bug constaté avec Safari, IE, etc... Je suppose les navigateurs coupables d'être un peu pleins de virus mais je n'ai pas de preuve.
Peut-être un bug du serveur, c'est un mutualisé.

Encore une fois ce bug est très rare et apparemment irrationnel.

Je connais la différence subtile entre Empty et isSet.

Le test pourrait être plus précis, tu as raison.
Cela dit, pour les ajouts au panier, Empty me semble plus juste que isSet car ajouter au panier une valeur nulle donnerait un résultat pas terrible...

Pour les form, mes balises sont bien fermées, je ne pense pas que le problème puisse venir de là (mais merci de tes suggestions, je vais y réfléchir).

La question est de savoir s'il est possible de corriger le bug quand il se produit.
Si c'était une variable de Session, il y avait des pistes dont on a discutées, mais, quand un navigateur a perdu $_POST, y a-il quelque chose à faire pour que la transmission de $_POST soit correcte quand le client, après avoir lu le message d'erreur, réessaye son ajout au panier ?

**nextdev** · 28/08/2010, 08h06

Bonjour,
Il y a aussi la déconnexion/changement d'ip qui peu provoquer perte de la session.

heuu il me semble...

**boteha** · 28/08/2010, 11h26

Bonjour,

Il y a aussi la déconnexion/changement d'ip qui peu provoquer perte de la session.

C'est $_POST qui est perdu.

En plus, le client reste connecté.
Il peut poursuivre ses consultations sans aucun problème, celles-ci ne faisant pas appel à $_POST.

Dans la série des bugs bizarres, j'en ai par parenthèse un autre à vous soumettre.

Les requêtes pour afficher des listes de produits passent par $_GET.
Si certaines variables $_GET sont absentes, il y a risque que la requête retourne toute la base de produits.

Donc, je teste la requête et je la bloque s'il manque la clause WHERE ou si WHERE retourne tout (du style WHERE produit LIKE '%')
Dans ce cas, je tiens un journal avec la requête, les variables $_GET et la provenance de la requête (HTTP_REFERER).

Dans 99 % des cas, HTTP_REFERER est vide.

Là encore, je ne comprends pas...
C'est aussi un bug rare, mais je ne comprends pas comment pas comment HTTP_REFERER peut être vide.
Des robots ?

Perte des variables de session

Langage PHP

Discussions similaires

Partager

Partager