Faut-il nettoyer les logs des jetons d'authentification utilisateur ?

RGJ · Septembre 13, 2024, 5:30

Nous avons un forum où user_auth_token_logs contient 61 millions de lignes (et ça continue d’augmenter).

Il n’y a que 25k user_auth_tokens.

Sur les 61 millions de lignes, 54 millions de lignes font référence à un user_auth_token qui n’existe plus (c’est-à-dire un problème d’intégrité de la base de données). Et sur les 61 millions de lignes, environ 58 millions ont plus de 2 mois (c’est-à-dire apparemment inutiles ?)

Questions :

Pourrions-nous simplement nettoyer cela sans risquer d’autres problèmes d’intégrité ?
Serait-il judicieux d’avoir un job pour nettoyer cela automatiquement ?

db=# select count(*) from user_auth_tokens;
 count 
-------
 25648

db=# select count(*) from user_auth_token_logs;
  count   
----------
 61415352

db=# select count(*) from user_auth_token_logs where user_auth_token_id not in (select id from user_auth_tokens);
  count   
----------
 54558442

db=# select count(*) from user_auth_token_logs where created_at < '2024-07-13';
  count   
----------
 58565943

pmusaraj · Septembre 13, 2024, 6:22

Oui, les user_auth_token_logs sont là uniquement à des fins de débogage. Toutes les lignes peuvent être vidées, la seule conséquence sera que vous n’aurez aucun journal pour déboguer.

Cela devrait être couvert par :

https://github.com/discourse/discourse/blob/main/app/jobs/scheduled/weekly.rb#L13

RGJ · Septembre 13, 2024, 7:07

Merci pour cela, je ne réalisais pas que c’était là.

Donc… le nettoyage ne s’exécute que lorsque verbose_auth_token_logging est true (ce qui n’est pas le cas sur cette instance)

mais la journalisation non détaillée se produit toujours, quel que soit le réglage

github.com/discourse/discourse

app/models/user_auth_token.rb

main


      
              auth_token: self.auth_token,
            )
          end
          
          def user
            impersonated_user || acting_user
          end

selon 8fb823c

Déplacement de ceci vers Bug

pmusaraj · Septembre 13, 2024, 7:45

Ah oui, bonne remarque. Il semble que les lignes 214 à 217 doivent également être corrigées.

Je serais à l’aise avec un nettoyage global après un certain délai. @osama (puisque vous êtes l’auteur du commit lié ci-dessus), pensez-vous que nous pouvons nettoyer tous ces journaux après un certain temps (et si oui, après combien de temps) ? Il semble que nous devions en conserver certains pour détecter des connexions suspectes.

RGJ · Septembre 13, 2024, 10:16

Pourquoi doit-elle être corrigée ? Ce morceau de code concerne le nettoyage des UserAuthToken ayant tourné, pas les enregistrements de journal ?

Mise à jour : après avoir activé SiteSetting.verbose_auth_token_logging, déclenché le travail hebdomadaire et exécuté VACUUM FULL user_auth_token_logs, la table est passée de 16 Go à 687 Mo

J’ai sauvé quelques arbres aujourd’hui

Osama · Septembre 16, 2024, 8:15

Oui, je pense que nous pouvons nettoyer la plupart des journaux, mais certains doivent rester. Plus précisément, je pense que tous les enregistrements qui ont suspicious, generate ou rotate comme action devront être conservés car ils sont utilisés pour détecter et générer des rapports sur les connexions suspectes.

github.com/discourse/discourse

app/models/concerns/reports/suspicious_logins.rb

501f07ab1


      
              title: I18n.t("reports.suspicious_logins.labels.login_time"),
            },
          ]
          
          report.data = []
          
          sql = <<~SQL
            SELECT u.id user_id, u.username, u.uploaded_avatar_id, t.client_ip, t.user_agent, t.created_at login_time
            FROM user_auth_token_logs t
            JOIN users u ON u.id = t.user_id
            WHERE t.action = 'suspicious'
              AND t.created_at >= :start_date
              AND t.created_at <= :end_date
            ORDER BY t.created_at DESC
          SQL
          
          DB
            .query(sql, start_date: report.start_date, end_date: report.end_date)
            .each do |row|
              data = {}

github.com/discourse/discourse

app/models/user_auth_token.rb

501f07ab1


      
              Math.sin((lat2_rad - lat1_rad) / 2)**2 +
                Math.cos(lat1_rad) * Math.cos(lat2_rad) * Math.sin((lon2_rad - lon1_rad) / 2)**2
            c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a))
          
            c * EARTH_RADIUS_KM
          end
          
          def self.is_suspicious(user_id, user_ip)
            return false unless User.find_by(id: user_id)&.staff?
          
            ips = UserAuthTokenLog.where(user_id: user_id).pluck(:client_ip)
            ips.delete_at(ips.index(user_ip) || ips.length) # delete one occurrence (current)
            ips.uniq!
            return false if ips.empty? # first login is never suspicious
          
            if user_location = login_location(user_ip)
              ips.none? do |ip|
                if location = login_location(ip)
                  distance(user_location, location) < SiteSetting.max_suspicious_distance_km
                end
              end

JonahAragon1 · Août 8, 2025, 4:11

Je vois sur mon forum que ce bug n’a jamais été corrigé

Le rapport de connexions suspectes ne semble s’appliquer qu’aux membres du personnel, y a-t-il une raison pour que ces journaux soient conservés pour les non-administrateurs ?

Pour que le rapport fonctionne, a-t-il besoin de données depuis le début de l’historique du compte ? Le journal peut-il être raccourci à quelque chose comme les 6 derniers mois ?

Pour le moment, il n’y a aucun nettoyage, ce qui pose un problème de confidentialité.

RGJ · Août 8, 2025, 4:31

Je ne comprends pas non plus la discussion ci-dessus.
Le bug est très simple : si le mode n’est pas verbeux, alors aucun nettoyage de UserAuthTokenLog n’est effectué, jamais. Le if doit disparaître.

L’implémentation d’origine ne journalisait que lorsque SiteSetting.verbose_auth_token_logging était vrai. Ce qui avait toujours le problème qu’après l’avoir désactivé, les journaux restants les plus récents resteraient, mais c’est une petite chose.

Mais ce changement a rendu la journalisation inconditionnelle (« Les journaux de jetons d’authentification generate, rotate et suspicious sont maintenant toujours enregistrés indépendamment du paramètre verbose_auth_token_logging »).

TLDR ; Ce changement a oublié de rendre la suppression inconditionnelle également.

sam · Août 11, 2025, 2:47

Bien sûr, nous allons régler cela au cours des prochaines semaines. S’il y a urgence, n’hésitez pas à nous soumettre une pull request (testée et confirmant que cela fonctionne comme prévu).

RGJ · Août 13, 2025, 10:05

J’ai créé une PR Fix: cleanup UserAuthTokenLog unconditionally by communiteq · Pull Request #34288 · discourse/discourse · GitHub, ce serait cool si elle était incluse dans la version 3.5.

RGJ · Août 14, 2025, 5:23

Et il semble que j’ai été devancé

github.com/discourse/discourse

FIX: Automatically clean up user_auth_token_logs

main ← jonaharagon:patch-1

opened 04:11PM - 10 Aug 25 UTC

jonaharagon

+45 -25

Fixes: https://meta.discourse.org/t/clean-up-user-auth-token-logs/326397?u=jonah…aragon1 Currently (since 2021 when this logging was [made unconditional](https://github.com/discourse/discourse/commit/8fb823c30f7fd3086f4370c2dc6e4e3737ae6acf)) all user IP addresses and user agent strings for all forum users are continuously logged and never cleared. Keeping unnecessary PII is a massive liability for us, so I hope this can be merged ASAP. I observe (in my user archive download) this indefinite logging does not happen on Meta, presumably because you have _verbose_ logging enabled, but it does happen on virtually all Discourse-hosted and self-hosted sites, which indicates to me this is unintended behavior. I should not have to enable verbose logging to _decrease_ the amount of logging here, but that is what I had to do as a temporary solution. This change will keep the logs for a few months by default. I can find no reason the logs should be kept longer, _especially_ as they only seem to be used for a feature (suspicious login reporting) which currently only applies to staff accounts and not regular users. cc: @OsamaSayegh

pmusaraj · Août 14, 2025, 5:13

En effet, cette PR est maintenant fusionnée grâce à @Osama. Elle traite la plupart des types de user_auth_token_logs, mais pas tous. Nous allons corriger les entrées generate sous peu. (Voir la discussion dans le lien PR ci-dessus pour plus de contexte).

Je vais garder ce sujet ouvert pendant que nous traitons le suivi.

Sujet		Réponses	Vues
User anonymization and staff_action_logs Support	7	700	Septembre 8, 2021
Logging checked_for_custom_avatar Bug	8	1086	Janvier 2, 2015
How to remove admin logs Support	15	2479	Novembre 15, 2023
Is there a limit to user_auth_token? Support	4	545	Juillet 9, 2021
Reset all login tokens Feature	7	2160	Mai 20, 2016

Faut-il nettoyer les logs des jetons d'authentification utilisateur&nbsp;?

Sujets connexes

Faut-il nettoyer les logs des jetons d'authentification utilisateur ?