Benutzer_auth_token_logs bereinigen?

RGJ · 13. September 2024 um 17:30

Wir haben ein Forum, in dem user_auth_token_logs 61 Millionen Zeilen hat (und es werden mehr).\n\nEs gibt nur 25.000 user_auth_tokens.\n\nVon den 61 Millionen Zeilen beziehen sich 54 Millionen auf einen user_auth_token, der nicht mehr existiert (d. h. ein Datenbank-Integritätsproblem). Und von den 61 Millionen Zeilen sind etwa 58 Millionen älter als 2 Monate (d. h. scheinbar nutzlos?)\n\nFragen:\n- Könnten wir das einfach bereinigen, ohne weitere Integritätsprobleme zu riskieren?\n- Wäre es eine Idee, einen Job zu haben, der das automatisch bereinigt?\n\n\ndb=# select count(*) from user_auth_tokens;\n count \n-------\n 25648\n\ndb=# select count(*) from user_auth_token_logs;\n count \n----------\n 61415352\n\ndb=# select count(*) from user_auth_token_logs where user_auth_token_id not in (select id from user_auth_tokens);\n count \n----------\n 54558442\n\ndb=# select count(*) from user_auth_token_logs where created_at < '2024-07-13';\n count \n----------\n 58565943\n\n

pmusaraj · 13. September 2024 um 18:22

Ja, user_auth_token_logs sind nur zu Debugging-Zwecken vorhanden. Alle Zeilen können geleert werden, die einzige Konsequenz ist, dass Sie keine Protokolle zum Debuggen mehr haben.

Dies sollte abgedeckt sein durch:

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

RGJ · 13. September 2024 um 19:07

Vielen Dank dafür, ich wusste nicht, dass das da ist.

Also… die Bereinigung läuft nur, wenn verbose_auth_token_logging auf true gesetzt ist (was auf dieser Instanz nicht der Fall ist).

aber nicht-verbose Logging findet immer statt, unabhängig von der Einstellung

github.com/discourse/discourse

app/models/user_auth_token.rb

main


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

gemäß 8fb823c

Dies wird zu Bug verschoben

pmusaraj · 13. September 2024 um 19:45

Ah ja, gut bemerkt. Es sieht so aus, als müssten Zeilen 214 bis 217 ebenfalls behoben werden.

Ich wäre mit einer globalen Bereinigung nach einer bestimmten Zeitspanne einverstanden. @osama (da Sie der Autor des oben verlinkten Commits sind), glauben Sie, dass wir all diese Protokolle nach einiger Zeit bereinigen können (und wenn ja, nach wie langer Zeit)? Es scheint, dass wir einige davon zur Erkennung verdächtiger Anmeldungen aufbewahren müssen.

RGJ · 13. September 2024 um 22:16

Warum muss das behoben werden? Bei diesem Codeausschnitt geht es um die Bereinigung von rotierten UserAuthTokens, nicht um die Log-Einträge?

Update: Nachdem SiteSetting.verbose_auth_token_logging aktiviert, der wöchentliche Job ausgelöst und VACUUM FULL user_auth_token_logs ausgeführt wurde, schrumpfte die Tabelle von 16 GB auf 687 MB

Heute ein paar Bäume gerettet

Osama · 16. September 2024 um 20:15

Ja, ich denke, wir können die meisten Protokolle bereinigen, aber einige müssen bleiben. Insbesondere denke ich, dass alle Einträge, die suspicious, generate oder rotate für die Aktion haben, aufbewahrt werden müssen, da sie zur Erkennung und Erstellung von Berichten für verdächtige Anmeldungen verwendet werden.

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 · 8. August 2025 um 16:11

Ich sehe, dass dieser Fehler in meinem Forum nie behoben wurde
Der Bericht über verdächtige Anmeldungen scheint nur für Mitarbeiter zu gelten. Gibt es einen Grund, warum diese Protokolle für Nicht-Administratoren aufbewahrt werden müssen?
Muss der Bericht, um zu funktionieren, Daten aus der gesamten Historie des Kontos enthalten? Kann das Protokoll auf beispielsweise die letzten 6 Monate gekürzt werden?
Derzeit gibt es keinerlei Bereinigung, was ein Datenschutzproblem darstellt.

RGJ · 8. August 2025 um 16:31

Ich verstehe die obige Diskussion auch nicht.

Der Fehler ist sehr einfach: Wenn der Modus nicht ausführlich ist, wird UserAuthTokenLog überhaupt nicht bereinigt, niemals. Das if muss weg.

Die ursprüngliche Implementierung hat nur protokolliert, wenn SiteSetting.verbose_auth_token_logging wahr ist. Das hatte immer noch das Problem, dass nach dem Deaktivieren die zuletzt verbliebenen Protokolle erhalten blieben, aber das ist eine Kleinigkeit.

Aber diese Änderung hat die Protokollierung bedingungslos gemacht („Die Protokolle generate, rotate und suspicious für Authentifizierungstoken werden jetzt immer protokolliert, unabhängig von der Einstellung verbose_auth_token_logging“).

TLDR; Diese Änderung hat vergessen, auch die Entfernung bedingungslos zu machen.

sam · 11. August 2025 um 02:47

Wir werden das in den nächsten Wochen in Ordnung bringen. Wenn es eilt, können Sie gerne einen PR (der getestet ist und bestätigt, dass er wie erwartet funktioniert) durchschicken.

RGJ · 13. August 2025 um 10:05

Ich habe einen PR erstellt Fix: cleanup UserAuthTokenLog unconditionally by communiteq · Pull Request #34288 · discourse/discourse · GitHub, es wäre cool, wenn dieser es für 3.5 schaffen würde.

RGJ · 14. August 2025 um 05:23

Und es scheint, ich war schneller

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 · 14. August 2025 um 17:13

In der Tat wurde dieser PR dank @Osama nun zusammengeführt. Er behebt die meisten Arten von user_auth_token_logs, aber nicht alle. Wir werden uns in Kürze um eine Korrektur für die generate-Einträge kümmern. (Weitere Informationen finden Sie in der Diskussion im obigen PR-Link).

Ich werde dieses Thema offen halten, während wir die Nachfolgearbeit erledigen.

Thema		Antworten	Aufrufe
User anonymization and staff_action_logs Support	7	701	8. September 2021
Logging checked_for_custom_avatar Bug	8	1086	2. Januar 2015
How to remove admin logs Support	15	2480	15. November 2023
Is there a limit to user_auth_token? Support	4	545	9. Juli 2021
Reset all login tokens Feature	7	2160	20. Mai 2016

Benutzer_auth_token_logs bereinigen?

Verwandte Themen