Discussion :

[Land3r]

Bonjour,

Voila, actuellement sur mes sites, pour compter le nombre de page vues ou de visites, j'effectue tout simplement une petite requête SQL ou j'incrémente le nombre de visites précédentes.

Cela marche très bien, mais pour des raisons d'optimisation, j'aimerais effectué une seule requête par session utilisateur (en incrémentant une variable dans ma session, et quand la session se supprime, additionner ce nombre avec celui déjà présent dans la BDD).

Seulement, je ne sais pas comment faire pour dire a PHP d'exécuter ma fonction qui sauvegardera dans la BDD le nombre de pages vues une seule fois par session et a la fin de la vie de la session, a sa suppression par exemple.

Je vous demande donc si vous avez des idées, ou alors une fonction PHP appelée lors de la suppression des sessions.

Merci d'avance

[sabotage]

Il n'est pas possible a ma connaissance d'intercepter la mise au rebut des sessions.

[alain31tl]

... (en incrémentant une variable dans ma session, et quand la session se supprime, additionner ce nombre avec celui déjà présent dans la BDD).

Slt

Oui, et de plus, ta variable incrémentée dans ta session serait aussi détruite si la session était supprimée, donc inexploitable.

Une solution, c'est d'obliger l'utilisateur à se déconnecter manuellement et intentionnellement, auquel cas au clic bouton, tu peux créer un script qui gére tes mises à jour finales.
Mais j'en doute vu que nombreux quitteront le navigateur et négligeront l'invitation à se déconnecter.

[djisse]

Salut.
Je pense que c'est possible si ma foi j'ai bien compris le problème!
Tu devrais creer a l'ouverture d'une session une variable de session. Ensuite dans toutes tes page tu met

Code :

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

1
2
3
4
5
6
7
8
9
<?php
if (isset$_SESSION['var'])
{
// le code du compteur pour les mebres.
}
else
{
// code a executer pour les non-membre
}

Est-ce ce dont tu as besoins?

[Séb.]

Comme le dit sabotage on ne peut pas intercepter la destruction des sessions, par contre on peut redéfinir la manière dont elles seront manipulées avec session_set_save_handler( ), notamment pour toi callbacks $destroy et $gc.
Cependant le garbage collector étant appelé aléatoirement les stats de consultation ne seront pas en temps réel.
A tester

[Land3r]

Sinon, j'ai pensé a une solution qui risque d'être plus simple a implémenter, mais qui risque de consommer plus.

Voila, je crée un répertoire temp, ou je crée pour chaque session créée, donc pour chaque visiteur en ligne, un fichier nommé avec le session_id et dedans le nombre 1 (1ere page vue vu que création de la session)

A chaque fois que la personne va voir une page, j'incrémente la valeur contenue dans ce fichier.

Jusque la aucun problème. Ensuite via un script bash inséré dans ma crontab, je fait appel a une page php environ toutes les 5 minutes. Cette page va comparer les répertoires : celui ou sont stockées mes sessions php, et le répertoire temp avec mes fichiers contenant le nombre de pages vues.
Théoriquement, a chaque fichier contenu dans temp, il doit correspondre une session. Lorsque je ne trouve pas cette correspondance, cela impliquerait donc que la session a été détruite ou alors session_regenerate_id(), mais si l'id a changé, il n'y a pas de problème, car cela va relancer une instance avec temp.
Donc si je ne trouve pas de correspondance, il me suffit alors de lire le fichier temp correspondant, et de rajouter la valeur dans la BDD

Qu'en pensez vous ? (Ce n'est que théorique pour l'instant ^^')

[FoxLeRenard]

Sinon, j'ai pensé a une solution qui risque d'être plus simple a implémenter, mais qui risque de consommer plus.
Voila, je crée un répertoire temp, ou je crée pour chaque session créée, donc pour chaque visiteur en ligne, un fichier nommé avec le session_id et dedans le nombre 1 etc ..

C 'est normal sur un forum de redire les choses Alors mets les paramétres suivant en mémoire et regardes ta solution.
1) si je suis sur ce forum, ma session a plein de données en mémoires ...
2) je suis appelé et qitte mon micro, qui reste sur cette page ... 30 minutes
3) je reviens, normalement ma session est HS (99% des serveurs sont a 15 minutes ) !

Donc tu as bien capté que de toute façon les sessions disparaissent d'elle même.

Autres aspects,
en général la session est en deux morceaux,
l' ID de la session qui est dans un cookies de session sur le micro du visiteur, ce cookies est supprimé dés que le visiteur quitte son navigateur ...
Les données de la session qui sont sur le serveur, et sont associées a l'ID de session.

Dernier point tu ne confonds pas les Cookies de données (par exemple login) qui restent tant que tu gardes tes cookies, même si tu éteind et redémarres ton micro, et le cookies de session !

Alors ça veut dire quoi en clair ?

1) il est totalement inutil d'effacer des données de session
2) il est impossible de lire les données d'une autre session, sauf hacke de l'ID

A toi de conclure

[Land3r]

J'avoue, j'ai pas tout suivi ^^.

Via cette technique, je ne chercherais pas a 'lire' les sessions a proprement parlé, mais de vérifier leur existence.
Ensuite, l'accès aux infos se fait uniquement via un autre fichier stocké dans le répertoire temp, donc je ne cherche pas 'accéder' a une session qui na m'a pas été accordé.

Et sinon, mes sessions sont conservées 24h dans le cas de mon application ^^'

Si tu pouvais clarifier la ou tu voulais en venir, je t'en serais reconnaissant

[FoxLeRenard]

J'avoue, j'ai pas tout suivi Si tu pouvais clarifier la ou tu voulais en venir, je t'en serais reconnaissant

Oui tu voudrais ecrire ces stats dans un fichier dont le nom serait par exemple son ID de session ?
Alors prenons la page 2
A chaque fois qu'il va a la page 2

Code :

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

1
2
3
4
5
6
7
 
<?PHP
session_start();
if (!isset($_SESSION['page2'])) 
{$_SESSION['page2']=1;$page2=1;}
 else {$page2=$_SESSION['page2']+1;}
// ===== et écriture du fichier

et ça il te suffit de le réécrire dans ton fichier ...
mais que vas tu faire quand il reviendra dans une heure ? son ID de session aura changée ?
alors quel fichier tu ouvrira ?

[Land3r]

Il suffit de stocker l'identifiant de session dans une autre variable et de la comparer.

Par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<?php
session_start();
if (!isset($_SESSION['initialisation']) || $_SESSION['identifiant_de_session'] !== session_id()) {
  // Ca veut dire que soit c'est la première page que la personne voit, soit il a un nouvel identifiant de session
  $_SESSION['initialisation'] = TRUE;
  $_SESSION['identifiant_de_session'] = session_id();
  // Donc je crée le fichier dans temp, et je met la valeur 1 dedans
}
else {
  // Donc c'est que ce n'est pas un nouveau fichier
  // Et la il suffit d'incrémenter la valeur du nombre de pages vues dans mon fichier dans temp
}

Comme cela, je pense que ça marcherait, je sais pas ce que tu en penses.
En tout cas, merci pour ta réactivité, je t'en suis reconnaissant.

[sabotage]

Je pense que c'est beaucoup plus adapté de le gérer dans une base de donnée : tout utilisateur qui n'a pas fait d'action depuis 30min est considerée deconnecté ; on n'a pas besoin de savoir si PHP a supprimé le fichier de session ou non.

D'ailleurs si je me souviens bien, l'expiration d'une session ne va pas forcemment de pair avec la suppression du fichier de session.

[Land3r]

Oui, tu as peut être raison, je voyais ça du coté ressource serveur ce serait peut être mieux, mais après tout, je vais faire une usine a gaz, pour pas grand chose. ^^

En tout cas, merci de m'avoir orienté !

[FoxLeRenard]

Je pense que c'est beaucoup plus adapté de le gérer dans une base de donnée : tout utilisateur qui n'a pas fait d'action depuis 30min est considerée deconnecté ; on n'a pas besoin de savoir si PHP a supprimé le fichier de session ou non.
D'ailleurs si je me souviens bien, l'expiration d'une session ne va pas forcemment de pair avec la suppression du fichier de session.

Salut l'Ami ,
Oui 100% OK avec toi, les données de session restent et sont purgées tout les ???
Seul la clé ID est en time-out
du reste si le visiteur est parti , laissant sa page et revient pour faire F5 le site web lui renverra session périmée

[alain31tl]

Bonjour à vous

Je prends un cas de figure classique.
1 - Un nouvel utilisateur s'inscrit.
2 - Il reçoit confirmation par mail de ses codes d'identification.
3 - L'utilisateur s'identifie et se connecte, une session est créée. ( Si login et pass inexistant dans la table session, voir plus bas )
4 - A ce moment précis, on sauvegarde ces infos dans une table sql.(session)
En l'occurence la session et ses variables (id de session, login, pass, etc, et tout ce qu'on veut, et pourquoi pas le nombre de pages vues et incrémentées.)

Jusqu'à présent, l'utilisateur ne s'était connecté qu'une seule fois.

L'utilisateur revient sur le site.
Le script doit permetre aussi de vérifier dans la table "session" , et avant connexion, si le login et le pass existe, si c'est le cas, on peut updater le nouvel id de session et par voie de conséquence conserver toutes les variables qui étaient associées à l'ancien id.

A l'inverse, et si le login et le pass n'existe pas, et bien on crée une session et on la sauvagarde.

C'est un petit tour de main mais ça marche, déjà testé.

Aprés, le reste, c'est une question d'organisation.

Edit :
Bien sûr, ceci nécessite 2 requêtes.
La première dans la table "membre"
La seconde dans la table "session"
En résumé, si inscrit dans la table membre, on vérifie dans la foulée si login et pass existe dans la table session.

[FoxLeRenard]

Bonjour à vous
C'est un petit tour de main mais ça marche, déjà testé.
Aprés, le reste, c'est une question d'organisation.

Ah mais 100% OK avec toi, ça marche, mais chez moi, pas question que je donne ma session a un site malicieux ... car tu saborde volontairement l'inviolabilitée de l'ID de session
(Heu... pour étre honéte inviolabilité pour le gus lambda )

[alain31tl]

Ah mais 100% OK avec toi, ça marche, mais chez moi, pas question que je donne ma session a un site malicieux ... car tu saborde volontairement l'inviolabilitée de l'ID de session
(Heu... pour étre honéte inviolabilité pour le gus lambda )

Mais Non Fox
Tu peux sauvegarder ce que tu veux sur SQL.
id de session, et variables infinies associées.

La seule chose que tu changes dans la table, c'est l'id de session chaque fois qu'un utilisateur se connecte.
Celà permet au moins qu'il puisse conserver toutes les infos précédentes.
C'est pas l'objectif souhaité ?

Je fonctionne pas hacker mais développeur.

EDIT : Pis en plus je saborde rien, puisque cette démarches s'effectue pendant la session et sur une unique session.

[Land3r]

Oui, ça pourrait être un système intéressant, mais on perd l'utilité de départ qui était d'économiser une incrémentation SQL.
A la place la, on doit vérifier a chaque page que l'utilisateur voit si l'id de session qui est stocké dans la BDD correspond toujours a celui utilisé par le membre.

Tu me dira, ça fait toujours plus qu'une requête au lieu de 2 ^^.

Sinon, tout simplement, a chaque membre, il faut attribuer un identifiant unique et qui ne varie pas (id_membre) et stocker le nombre de pages vues par ce membre dans un fichier nommé avec son id_membre.
Pas d'effacement de fichiers qui restent alors a vie, et pour connaitre le nombre de pages vues au total, il suffit de lister le répertoire et d'additionner les valeurs comprises dans les différents fichiers et de stocker le résultat dans ma BDD pour économiser le calcul a chaque fois

Après genre, je met ça a jour toute les heures avec une tache cron.
En plus, de cette manière, je peut garder l'historique des connexions pour savoir tel mois combien il y en a eu etc (il suffit de comparer la première valeur dans ma BDD du nombre de visites sur le mois de juin et comparer ca avec la première de juillet pour avoir les visites du mois de juin.)

Je pense que je vais m'orienter vers ce systeme

[alain31tl]

...A la place la, on doit vérifier a chaque page que l'utilisateur voit si l'id de session qui est stocké dans la BDD correspond toujours a celui utilisé par le membre....

Et bien non, puisque cet id de session demeurera tant qu'il reste connecté.
Alors pourquoi le vérifier ?

Un peu plus de clarté :
Quand on utilise ce système de session php, l'intérêt principal et d'associer à l'id de session, différentes variables utiles et susceptibles d'être exploitées durant cette fameuse session.
Sinon, je n'en vois pas l'utilité.

Le probléme, c'est la durée de vie de cette session. Si l'utilisateur se déconnecte, l'id de session est "mort" et les variables associées sont "mortes".

D'où l'intérêt d'une part, de sauvegarder sur sql les sessions, et d'autre part d'updater le nouvel id de session à la connexion suivante. (Autrement dit, écraser en lieu et place le précédent)
Et ainsi de retrouver ttes les anciennes variables existantes dans celui détruit.

PS : Pis faut pas se poser de question sur un X nombre de requêtes.
Des scripts de 500 lignes, php les gére parfaitement et on ne voit quasimment pas de différence de traitement par rapport à un script de 20 lignes .... quand il est bien réalisé.

[Land3r]

Oui mais dans mon cas d'application, je dois gérer plusieurs centaines de connecté simultané.

Ça en fait des requêtes SQL a la seconde ^^.
C'était pour un soulager au maximum le serveur SQL

[alain31tl]

Dans ce cas, on ne peut pas grand chose, sessions ou pas.
On ne fait pas des miracles avec du minimum, sinon voir avec ton hébergeur les possibilités d'augmenter tes capacités de trafic web.