Bitte kurze Ruby-Skript zur Sperrung inaktiver Benutzer auswerten

[TonyG]

Dies ist mein allererstes benutzerdefiniertes Ruby-Skript. In fast 50 Jahren Programmierung mit über 20 Sprachen und Dialekten musste (oder wollte ) ich noch nie in Ruby schreiben, aber OK, du hast mich erwischt … bitte sei sanft.

Mein Ziel ist es, Benutzerkonten zu identifizieren, die nicht per E-Mail-Link authentifiziert wurden, und die Konten zu sperren, damit ich sie vor der Löschung überprüfen kann. Während der Ersteinrichtung hatte ich Einstellungen in verschiedenen Entwicklungsstadien. Die 2FA-E-Mails wurden für einige Registrierungen nicht versendet, und es gab viele fehlerhafte Registrierungen, die ich jetzt herausfiltern möchte.

Version 0.0.1

rails c

# Stellen Sie zunächst sicher, dass die Benutzer-TLs den neuesten Definitionen entsprechen
User.all.find_each do |user|
  Promotion.recalculate(user)
end
Group.ensure_consistency!

# Vorbereitung für die Schleife
logger = StaffActionLogger.new(User.where("id = 'admin'"))
# temporäres Datum, Benutzer werden vor diesem Datum entfernt
suspend_till = DateTime.new(2028, 12, 31)
suspend_at = DateTime.now
reason = 'Inactive'

# Potenziell tote Konten identifizieren
User.where("views = 0 OR approved = FALSE OR last_seen_at IS NULL")
    .where("id > 0")
    .find_each do |user|
  user.suspended_till = suspend_till
  user.suspended_at = suspend_at
  user.change_trust_level!(TrustLevel[0])
  # den Benutzer speichern, die Aktion protokollieren und ... das tun, was für diesen Auslöser getan wird
  user.save!
  logger.log_user_suspend(user, reason)
  DiscourseEvent.trigger(:user_suspended, user: user)
  # den Mailserver nicht missbrauchen
  sleep(10)
end

Durch das Auslösen des Ereignisses möchte ich, dass E-Mails an die Benutzer gesendet werden - es wird eine Menge Bounces geben, und es wird vielleicht ein paar Leute geben, die zurückkommen, um sich zu authentifizieren. Nach einer Woche werde ich alle noch gesperrten Konten auswählen und löschen.

Fragen:

1. Wird dies im Allgemeinen das tun, was beabsichtigt ist?
2. Gibt es einen besseren Ansatz?
3. Ist die Protokollierung redundant mit dem Ereignisauslöser?
4. Können wir das mit JavaScript machen?
5. Sollte ich das in eine andere Kategorie posten?
6. Gibt es weitere Ratschläge?

Danke!!

[TonyG]

Hmm, wenn ich mir das so ansehe, denke ich, ich sollte ein Konto stummschalten und nicht sperren. Wenn das Konto gesperrt ist, kann sich der Benutzer nicht anmelden, um das Konto zu beanspruchen.

Hier ist eine Überarbeitung …

Version 0.0.2

silence_reason = 'Inactive'
User.where("views = 0 OR approved = FALSE OR last_seen_at IS NULL")
    .where("id > 0") # vermeide Systembenutzer
    .find_each do |user|
  user.silence(reason: silence_reason)
  user.change_trust_level!(TrustLevel[0])
  user.save!
  logger.log_user_silence(user, silence_reason)
  DiscourseEvent.trigger(:user_silenced, user: user)
  sleep(5)
end

Ja, ich werde vorher ein Backup machen.
Ja, ich weiß, dass einige bestehende TLs neu zugeordnet werden und ich sie korrigieren muss.

Sollte ich zusätzlich zum Stummschalten oder anstelle des Stummschaltens Approved=false oder Active=false setzen? Ich glaube, das zwingt den Benutzer, auf den E-Mail-Link zu klicken, anstatt manuell ein Login durchzuführen, was dem Zweck der Validierung der E-Mail-Adresse dient.

Dies alles bezieht sich auf meinen letzten Thread: notes-on-silencing-or-deleting-users

[EDIT]
Ich habe auch “purge unactivated users grace period days” auf 7 gesetzt.
Setzt eine Stummschaltung oder Sperrung dies zurück? Wenn ja, wenn Leute nicht innerhalb von 7 Tagen auf eine Kontoaktion reagieren, habe ich kein Problem damit, sie zu löschen.

Schließlich (ja, wirklich) habe ich auch “clean up inactive users after days” auf 365 gesetzt. Ich kann das auf 60 reduzieren, während das Forum noch geöffnet wird, und einfach bestehende Konten von der Liste fallen lassen. Dann wieder auf 365 erhöhen. Ist das ein vernünftiger Ansatz für die automatische Bereinigung von Konten in einer neuen Umgebung?

[pfaffman (Jay Pfaffman)]

@Tony G

Ich habe auch „Grace Period für unaktivierte Benutzer löschen“ auf 7 gesetzt.

Warum reicht das nicht aus, um Ihr Problem zu lösen?

@Tony G

User.where(„views = 0 OR approved = FALSE OR

Sollte das nicht AND statt OR sein?

@Tony G

was dem Zweck dient, die E-Mail-Adresse zu validieren.

Discourse erzwingt diese, um Adressen zu validieren, daher ist mir nicht ganz klar, welches Problem Sie lösen. Sie sagen das

@Tony G

Ich möchte, dass E-Mails an die Benutzer gesendet werden – es wird eine Reihe von Bounces geben und vielleicht kommen ein paar Leute zurück, um sich zu authentifizieren.

Es erscheint ziemlich unwahrscheinlich, dass Sie Benutzer finden werden, die sich anmelden wollten, aber vorher nicht konnten, aber vielleicht wissen Sie etwas über Ihr Setup, das ich nicht weiß.

Und Discourse sendet keine E-Mails an Adressen, die nicht validiert sind, daher glaube ich nicht, dass dies E-Mails versenden wird.

Ich mache diese Dinge immer bei ein paar Konten, aber von Hand, um zu sehen, was passieren wird.

[TonyG]

Vielen Dank für Ihr Interesse, @pfaffman!

@TonyG

Ich habe auch „purge unactivated users grace period days“ auf 7 gesetzt.

@pfaffman

Warum reicht das nicht aus, um Ihr Problem zu lösen?

Es gibt Benutzereinträge ohne last_seen_at, die vor Monaten erstellt wurden, approved=False, active=False, und sie werden nicht gelöscht.
Es gibt Benutzereinträge mit last_seen_at > 7 Tagen (Monate alt) und 0 Aufrufen, und sie werden nicht gelöscht.

Welche Kriterien auch immer für dieses Grace-Period-Flag verwendet werden, sie wählen diese Einträge nicht aus.
Kann jemand die genaue Abfrage posten, die dort verwendet wird, damit ich verstehen kann, welche anderen Faktoren dabei eine Rolle spielen?

@TonyG

User.where("views = 0 OR approved = FALSE OR last_seen_at IS NULL")

@pfaffman

Sollte das nicht AND statt OR sein?

Nein, wenn ich die Datenbank direkt betrachte, gibt es Benutzereinträge, die jedes Kriterium erfüllen, aber nicht alle. Es scheint, dass die Benutzertabelle in der Datenbank inkonsistent ist. Es gibt Einträge mit non-zero topics_entered oder posts_read_count, aber mit views=0. Es gibt Einträge mit topics_entered=0 und posts_read_count=0, aber views ist non-zero.

Der wichtigste Punkt, den man sich merken muss, ist, dass während der Entwicklung dieser Website die Einstellungen nicht optimal waren und Menschen und Bots registriert wurden. Die OR-Klausel scheint all diese zu erfassen. Jetzt, da die Website stabilisiert ist mit (hoffentlich) vernünftigen Einstellungen, erwarte ich nicht, dass neue Registrierungen zu den gleichen Anomalien führen.

Ich beabsichtige, das Skript viele Male mit unterschiedlichen Kriterien auszuführen. Ich werde zuerst Einträge abfragen, außerhalb der Umgebung, und dann das Stille-Skript ausführen, um nur die Einträge anzusprechen, die ich wirklich will. In ein paar Wochen werde ich einen letzten Durchlauf machen, nur die stillgelegten Einträge auswählen (jeder, der tatsächlich zurückkam, wird das Flag entfernt bekommen) und alle davon löschen:

UserDestroyer.new(admin_user).destroy(user, reassign_to: archive_user)

Meine allgemeine Frage ist, ob das v0.0.2-Skript mit seinem Ansatz zur Auswahl, Protokollierung und Stummschaltung für ein Discourse-System korrekt ist. Ich weiß nicht, ob in einer solchen Schleife noch etwas anderes getan werden muss. Ich habe noch nie ein eigenes Skript erstellt und ausgeführt, daher ist dies eine Bitte, mich auf Noob-Fehler zu überprüfen.

Danke!!