Suivi — Comptes utilisateurs Pouvoir déterminer si un compte a eu de l'activité récemment

#2054 Posté par Adrien Dorsaz (site web personnel, Mastodon) le 17 février 2023 à 11:18. État de l’entrée : corrigée. Assigné à Adrien Dorsaz. Licence CC By‑SA.

Étiquettes : aucune

fév.

2023

Pour le projet de nettoyage des très vieux comptes, nous avons besoin d'un moyen fiable pour savoir si un compte est encore actif ou non.

Une discussion a commencé sur la dépêche pour savoir comment déterminer ça et, finalement ce n'est pas si évident.

Le système d'authentification utilisé est devise 4.6.2.

Actuellement, nous les fonctionnalités suivantes sont activées:

registerable: permet de s'inscrire sur le site
confirmable: demande une confirmation par email pour créer un compte
database_authenticatable: stock en base le hash du mot de passe
recoverable: la fonctionnalité "mot de passes perdu"
rememberable: ajoute la fonctionnalité "se souvenir de moi"
trackable: ajoute quelques champs en base pour suivre l'état des connexions

Le cookie par défaut d'authentification (sans cocher la case "se souvenir de moi") a une durée de validité liée à la Session du navigateur. Donc, si l'utilisateur active la fonctionnalité "Se souvenir de ma session / Réouvrir les onglets au démarrage" de Firefox (ou autres navigateurs), sa connexion sera active à vie et les modules trackable et rememberable sont à priori inutiles pour déterminer si l'utilisateur s'est connecté récemment.

Il faudrait lire plus en détail ce que permet devise, le résumer ci-dessus est un rapide point de ce que j'ai constaté, je n'ai pas lu toute la documentation.

Un autre point que l'on peut utiliser pour savoir si un compte a eu de l'activité récente serait les champs updated_at automatiques de Ruby On Rails sur les tables account et user. Le problème de ces champs, c'est que les actions de modérateurs sur les comptes peuvent aussi mettre à jour ces champs. En plus, ils demandent à l'utilisateur de modifier son profile / son compte pour les mettre à jour, ce n'est pas très naturel.

# last_seen_at

Posté par nud le 17 février 2023 à 16:23. Évalué à 2 (+0/-0). Dernière modification le 17 février 2023 à 16:26.

Par rapport au problème posé, je suppose que le plus simple serait d'ajouter un last_seen_at qui serait mis à jour à chaque page vue.

Comme en vrai ça ne sert à rien de mettre à jour à chaque page vue je propose de le faire avec une granularité qui serait par exemple une journée, càd un champ de type "date" plutôt que "datetime". Comme ça pas besoin de le mettre à jour sans arrêt, ça minimise les UPDATE. Une semaine ou un an ça peut aussi convenir.

Tracker le "last seen" permet aussi de ne pas supprimer les comptes des gens qui commentent/moinssent peu. Et c'est plus facile à faire.

Répondre
- [^] # Re: last_seen_at
  
  Posté par Adrien Dorsaz (site web personnel, Mastodon) le 17 février 2023 à 19:57. Évalué à 2 (+0/-0).
  
  Apparemment cette solution est proposée dans la partie sécurité du gzide de Rails pour s'assurer que les sessions expirent au bout d'un moment : https://guides.rubyonrails.org/security.html#session-expiry
  
  Répondre
  - [^] # Re: last_seen_at
    
    Posté par Adrien Dorsaz (site web personnel, Mastodon) le 17 février 2023 à 20:10. Évalué à 2 (+0/-0).
    
    C'est pour corriger la fonctionnalité quand la case "se souvenir de moi" n'est pas cochée.
    
    Quand on fera le script de nettoyage il faudra bien penser à verifier les 2 champs "current_sign_in_at" et "remember_created_at".
    
    Pas sûr de ce qu'est cette dernière colonne, si ça ne joue pas, rememberable permet d'ajouter un callback "after_remembered".
    
    Répondre
  - [^] # Re: last_seen_at
    
    Posté par Adrien Dorsaz (site web personnel, Mastodon) le 17 février 2023 à 20:23. Évalué à 2 (+0/-0). Dernière modification le 17 février 2023 à 20:26.
    
    Ah, c'est encore plus simple, il faut ajouter la fonctionnalité :timeoutable à devise et la configurer, la valeur par défaut est de 30 minutes d'inactivité, c'est peut être un peu court.
    
    Par contre, je n'arrive pas à savoir avec leur doc, si ça se repose juste sur le expiration time du cookie ou si c'est aussi fait niveau serveur.
    
    Répondre
    - [^] # Re: last_seen_at
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 13 avril 2023 à 21:57. Évalué à 2 (+0/-0). Dernière modification le 13 avril 2023 à 21:57.
      
      Bon, j'ai essayé et j'ai compris que timeoutable semble tracker l'activité avec des données directement dans le cookie et non pas en base de donnée. Ça ne serait donc pas si utile que ça.
      
      J'ai testé avec un timeout par exemple d'une minute et, en fait, tant que je navigue sur le site, le cookie reste valable et la base de donnée n'est pas mise à jour. C'est parce qu'il détruit la session seulement si l'utilisateur est inactif un certain temps et non pas après une certaine durée de session.
      
      Devise ne semble pas proposer de forcer un temps maximal de session, du coup, je pense que ça ne sert pas à grand chose de changer sa configuration et il vaut mieux implémenter la proposition de nud.
      
      Répondre
- [^] # Re: last_seen_at
  
  Posté par Adrien Dorsaz (site web personnel, Mastodon) le 06 mai 2023 à 15:04. Évalué à 2 (+0/-0). Dernière modification le 06 mai 2023 à 15:04.
  
  Voilà, j'ai préparé une pull request ici pour ajouter une colonne "last_seen_on": https://github.com/linuxfrorg/linuxfr.org/pull/370
  
  La valeur est NULL tant que le compte n'a pas été confirmé (et donc aussi pour Anonyme et Collectif). Si non, ce sera la date de la migration, parce qu'on ne peut pas savoir précisément la bonne date à mettre.
  
  Répondre
  - [^] # Re: last_seen_at
    
    Posté par Benoît Sibaud (site web personnel) le 31 mai 2023 à 20:50. Évalué à 4 (+0/-0). Dernière modification le 31 mai 2023 à 20:50.
    
    Fusionné et déployé. Cf https://github.com/linuxfrorg/linuxfr.org/commit/7d3fd821a4c041cfe2313657b26a93d91d68aa5c
    
    Répondre
# Timestamps SQL

Posté par Benoît Sibaud (site web personnel) le 19 février 2023 à 14:31. Évalué à 3 (+0/-0).
Les infos temporelles en base SQL susceptibles d'être utiles pour mesure l'activité/l'inactivité d'un compte (mais tout est toujours compliqué, entre l'historique, les changements de logiciel, les opérations manuelles en base à une époque, …) :
- nb
  - ne pas oublier d'exclure Anonyme et Collectif des traitements
  - la table badges devrait être supprimée (elle est vide)
  - si on connaît mal les comptes actifs, alors on a un souci sur les statistiques des utilisateurs
  - mentionner les oauth_applications associées à la fermeture d'un compte dans les règles de gestion
  - nettoyer les oauth_access_grants révoqués (1539 sur 1599) passés un certain délai, y compris pour les comptes actifs ?
- contenus créés (bookmarks.created_at, bookmarks.created, diaries.created_at, news.created_at, polls.created_at, posts.created_at, trackers.created_at, wiki_pages.created) et les indirects news_versions.created_at et wiki_versions.created_at : la date n'est pas modifiée en suite. Verdict: Utile pour repousser la fermeture faute de mieux, par contre tout le monde ne créé pas de contenus.
- nodes.created_at devrait donner la même info que la précédente, à quelques secondes près (verdict: inutile pour notre besoin):
  - pour les contenus non modérés a priori ([0,2s] pour les bookmarks, [0,61s] pour les diaries, [-1d, 41s] pour les posts, étrange mais pas important ici, [0,4041s] pour les trackers, [0, 1s] pour les wiki_pages)
  - mais ça peut varier beaucoup, plusieurs années, pour les contenus modérés a priori qui ont patienté longtemps en rédaction/modération comme news et polls)
- commentaires créés (comments.created_at) : la date n'est pas modifiée en suite. Par contre tout le monde ne commente pas. Verdict: Utile pour repousser la fermeture faute de mieux.
- étiquetages créés (taggings.created_at) : la date n'est pas modifiée en suite. Par contre tout le monde n'étiquette pas. A priori pas éligible au droit d'auteur, donc pas forcément utile de conserver l'association au user_id si on peut autrement supprimer le compte (on réaffecte à Anonyme). Verdict: Utile pour repousser la fermeture faute de mieux.
- uniquement pour les administrateurs : categories.created_at, categories.updated_at, forums.created_at, forums.updated_at, pages.created_at, pages.updated_at, sections.created_at, sections.updated_at)
- mises à jour de contenus (verdict: inutile ici):
  - limités à l'équipe du site (bookmarks.updated_at, diaries.updated_at, polls.updated_at) et ne renseignent pas sur l'activité du compte concerné
  - le compte ou l'équipe du site (̀posts.updated_at, trackers.updated_at, poll_answers.created_at, poll_answers.updated_at, news.submitted_at) donc pas utilisable non plus ici
  - plusieurs comptes (wiki_pages.updated_at, news.updated_at)
  - nodes.updated_at, nodes.last_commented_at : influencé par le score, le dernier commentaire, etc. Verdict: inutile pour notre besoin
- links.created_at, links.updated_at : autant se baser sur la dépêche…
- mises à jour de commentaires (verdict: inutile pour notre besoin) : reflète initialement les éventuelles modifications par le compte pendant la période initiale, mais aussi les corrections par l'équipe du site ou simplement le score
- friendly_id_slugs.created_at nous dira juste si le compte ou l'équipe du site a eu besoin de renommer quelque chose (verdict: inutile pour notre besoin)
- logs.created_at nous dira qui a fermé le compte et quand (verdict: utile, mais juste pour les comptes fermés)
- autorisations données et tokens pour les applications, par le compte oauth_access_grants.created_at, oauth_access_grants.revoked_at, oauth_access_tokens.created_at, oauth_access_tokens.revoked_at (verdict: utile pour repousser la fermeture faute de mieux)
- oauth_applications.updated_at : a priori ça ne va pas forcément nous aider
- création de comptes : users.created_at et accounts.created_at
- confirmation du compte : accounts.confirmed_at et accounts.confirmation_sent_at (verdict: si les deux sont NULL et le rôle inactive, alors on peut virer ; mais si le rôle est différent, on n'apprend rien)
- mise à jour de accounts.updated_at, reset_password_sent_at: changement de rôle, changement de karma, changement de feuille de style, d'adresse de courriel, demande de renvoi de courriel, se loguer, modifier les préférences -> verdict: inutile
- mise à jour de users.updated_at: modifier son nom, ses adresses de site perso/mastodon, son avatar, sa signature -> a priori rien qui ne soit modifiable par un autre compte, et rien qui bouge après la fermeture du compte. Verdict: utile pour repousser la fermeture faute de mieux
- accounts.remember_created_at ne marche que pour la fonctionnalité "se souvenir de moi"
- accounts.current_sign_in_at (forcément mieux que accounts.last_sign_in_at) ne marche que si les sessions sont oubliés côté navigateur
Répondre
- [^] # Re: Timestamps SQL
  
  Posté par Benoît Sibaud (site web personnel) le 25 février 2023 à 18:16. Évalué à 3 (+0/-0).
  
  ~~la table badges devrait être supprimée (elle est vide)~~
  
  fait
  
  ~~si on connaît mal les comptes actifs, alors on a un souci sur les statistiques des utilisateurs~~
  
  à défaut, maintenant on parle de « comptes valides et s’étant connectés au cours des trois derniers mois » plutôt que de « comptes valides et utilisés au cours des trois derniers mois » dans les statistiques
  
  Répondre

# Un peu de suivi de l'évolution

Posté par Benoît Sibaud (site web personnel) le 03 juin 2023 à 10:52. Évalué à 3 (+0/-0).

SELECT COUNT(*), last_seen_on, role<>'inactive' as active FROM accounts GROUP BY last_seen_on, active;
+----------+--------------+--------+
| COUNT(*) | last_seen_on | active |
+----------+--------------+--------+
|     1413 | NULL         |      0 | // vieux comptes fermés ou jamais utilisés, avec  current_sign_in_at / last_sign_in_at NULL
|        1 | NULL         |      1 | // anonyme
|     2617 | 2023-05-31   |      0 | // début du décompte d'ancienneté pour les comptes précédemment fermés
|    28857 | 2023-05-31   |      1 | // début du décompte d'ancienneté pour les comptes toujours ouverts
|      195 | 2023-06-01   |      1 | // comptes actifs qui sont passés le 1er juin mais pas depuis
|      478 | 2023-06-02   |      1 | // comptes actifs qui sont passés au moins le 2 juin mais pas depuis
|        1 | 2023-06-03   |      0 | // compte de spammeur fermé aujourd'hui
|      236 | 2023-06-03   |      1 | // comptes actifs qui sont d'ores et déjà passés aujourd'hui
+----------+--------------+--------+

[^] # Re: Un peu de suivi de l'évolution

Posté par Benoît Sibaud (site web personnel) le 10 juillet 2023 à 11:51. Évalué à 3 (+0/-0). Dernière modification le 10 juillet 2023 à 12:23.

SELECT COUNT(*), WEEK(last_seen_on) FROM accounts GROUP BY week(last_seen_on);
+----------+--------------------+
| COUNT(*) | WEEK(last_seen_on) |
+----------+--------------------+
|     1438 |               NULL |
|    30509 |                 22 |
|       89 |                 23 |
|      155 |                 24 |
|      138 |                 25 |
|      272 |                 26 |
|      663 |                 27 |
|      663 |                 28 |
+----------+--------------------+

On a donc 2032 comptes (2019 encore actifs) vus dans les 40 derniers jours, ce qui est d'ores et déjà supérieur aux « 1821 comptes valides et s’étant connectés au cours des trois derniers mois » actuellement utilisé pour les statistiques sur les utilisateurs.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.