Projet

Général

Profil

Anomalie #19814

Mélange de plusieurs visiteurs derrière forward et/ou reverse proxy

Ajouté par Renaud Dussol il y a environ 7 ans. Mis à jour il y a presque 7 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
Début:
21/03/2017
Echéance:
% réalisé:

100%

Distribution:

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

Révision 02583aaa (diff)
Ajouté par Arnaud Fornerot il y a environ 7 ans

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

#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é

Formats disponibles : Atom PDF