Anomalie #19814
Mélange de plusieurs visiteurs derrière forward et/ou reverse proxy
100%
Description
Nous avons constaté que Piwik agrégeait des visites qui étaient vraisemblablement différentes
En effet, suite à la bascule en 2.5, nous avons constaté une baisse du nombre de visites/visiteurs uniques, alors que le nombre d'actions restait le même
Corollairement, le nombre d'actions par visite avait considérablement augmenté
En regardant dans le log visiteurs, nous avons alors vu plusieurs visites de 500 actions (qui semble être une limite mais il y en a sans doute plus) et qui durent plusieurs heures (jusqu'à 16 ou 18)
Les IP, anonymées en 0.0 semblaient être les mêmes (192.168.0.0, certainement celle de notre reverse-proxy)
Afin de tester, nous avons temporairement désanonymisé l'IP
Nous avons constaté alors que l'IP enregistrée par piwik était celle du reverse-proxy
Ce cas est géré par piwik, il suffit d'ajouter au fichier de configuration, dans la section [General], les 2 lignes suivantes :
proxy_client_headers[] = "HTTP_X_FORWARDED_FOR"
proxy_host_headers[] = "HTTP_X_FORWARDED_HOST"
Une fois ces lignes ajoutées :
- Le comportement a changé : le nombre de visites/visiteurs unique a augmenté et le nombre d'actions par visite a baissé, sans toutefois atteindre les niveaux d'avant la bascule
- Les IP étant toujours désanonymées, nous avons pu constater encore des visites de plus de 500 actions mais de durée moins longue (7-8 heures), mais surtout nous avons pu voir que les IP étaient celles de nos deux forward-proxy (squid), celui du rectorat et celui de la zone administrative en établissement.
En effet, le trafic étant entièrement en HTTPS, les squid ne peuvent insérer l'en-tête X-Forwarded-for dans le flux, et donc l'IP du client est perdue
Le problème, c'est que visiblement, (voir demande https://dev-eole.ac-dijon.fr/issues/13577 et la réponse), le principal discriminant pour l'identification d'un visiteur est l'IP
Ceci pose un réèl problème pour un trafic qui passe derrière un forward-proxy, ce qui je pense sera souvent le cas pour un PIA, notamment côté réseau administratif d'établissement
Une donnée très intéressante à ce titre est le nombre maximum d'actions par visite.
Avant la bascule en 2.3, il plafonnait à 700 (ce qui est déjà énorme, et sans doute y avait-il déjà un problème en 2.3). Pour comparer, on peut voir que pendant les périodes de vacances et week-ends, (donc périodes ou personne n'utilise de forward-proxy), ce nombre oscille entre 30 et 50, ce qui semble plus réaliste.
Pendant la période ou la seule IP enregistrée était celle du reverse-proxy, ce chiffre était monté à 2500, avec un pic à 3600, ce qui montre bien l’agrégation de visites différentes (durant les Week-ends : 1200)
Une fois la configuration modifiée pour utiliser X_FORWARDED_FOR, le nombre rechute à 700, mais curieusement semble remonter ensuite (on est en pleine campagne de mutations enseignants, ce qui pourrait expliquer ce fort taux)
En tout cas, une chose simple à faire : quand la variable "activer_web_behind_revproxy" est à "oui", il faut ajouter les deux lignes
proxy_client_headers[] = "HTTP_X_FORWARDED_FOR"
proxy_host_headers[] = "HTTP_X_FORWARDED_HOST"
au fichier config.ini.php
Ce qui permet déjà de contourner le problème de l'IP du reverse proxy
En revanche, quand une bonne moitié, voire plus des utilisateurs passent par un forward-proxy à travers du HTTPS, je ne vois pas de solution telle quelle
Il faudrait voir s'il n'y a pas un autre moyen de discriminer les visites et visiteurs uniques dans piwik que l'IP
Dans la mesure ou ces visiteurs ont une session CAS, n'y aurait-il pas moyen de dire à la sonde piwik d'envoyer un id utilisateur (qui ne serait pas l'uid mais un nombre calculé aléatoirement tout en étant basé sur l'uid) ?
Ou bien notre configuration n'est-elle pas bonne ? Sur la doc de piwik je vois que l'on peut apparemment appeler la sonde avec un uid(crypté), mais le fichier envoleTrackeur.js.php, n'est jamais appelé avec ce paramètre chez nous. Il semble aussi possible d'utiliser les cookies (https://piwik.org/faq/how-to/faq_175/)...
Bref nous sommes preneurs de toute idée ou conseil
Révisions associées
ajout des options nécessaire pour tracker convenablement le visiteur (fixes #19814)
Historique
#1 Mis à jour par Renaud Dussol il y a environ 7 ans
Le paramètre trust_user_cookies donne de bons résultats, bien meilleurs que l'IP
Pour l'uid (qui d'après piwik est le plus fiable), voir si inclusion possible de envoleProfil.php (qui initialise la session CAS) dans envoleTrackeur.php
Dans envoleTrackeur,
juste avant la fonction js
<?php include "envoleProfil.php";
$uid = $details['infos']['uid'][0];
?>
puis à l'intérieur de la fonction :
piwikTracker.setUserId('<?php echo $uid; ?>');
Pose peut-être pb avec certaines applis
et vérifier si cela fonctionne sur le serveur piwik
#2 Mis à jour par Renaud Dussol il y a environ 7 ans
Pour activer la gestion des cookies, dans le fichier config.ini.php
dans la section [Tracker]
ajouter :
trust_visitors_cookies = 1
Cette config semble donner de bons résultats, après quelques semaines de recul
#3 Mis à jour par Anonyme il y a environ 7 ans
- Statut changé de Nouveau à Résolu
- % réalisé changé de 0 à 100
Appliqué par commit 02583aaac84f0c9e25a717dd3a554e4c3f4b1720.
#4 Mis à jour par Arnaud FORNEROT il y a environ 7 ans
- Version cible mis à Envole 5.5
#5 Mis à jour par Arnaud FORNEROT il y a environ 7 ans
- Tracker changé de Demande à Anomalie
#6 Mis à jour par Arnaud FORNEROT il y a presque 7 ans
- Statut changé de Résolu à Fermé