Hallo zusammen ![]()
Ich entschuldige mich im Voraus für diesen langen Beitrag, aber vielleicht kennt sich jemand mit Discourse aus und hat sofort Antworten.
Ich leite gemeinsam einen spezialisierten Forum-Betrieb, der moderiert wird. Wir sind zu zweit, und der andere Kollege hat die Software geschrieben (ebenfalls in Ruby). Das bestehende Forum ist eine vollständig benutzerdefinierte Software, die sich durch ihre Einfachheit im Vergleich zu z. B. PHP-BB und Vbulletin auszeichnet (und diese werden ständig gehackt). Die Datenbank hat etwa 40 GB und enthält 200.000 Beiträge. Aus verschiedenen Gründen prüfen wir derzeit eine Migration der Datenbank auf eine andere Plattform, und Discourse scheint dafür geeignet zu sein.
Vorläufige Tests deuten darauf hin, dass die Gesamtfunktionalität sehr gut ist, z. B. die Unterstützung für das Einbetten von Bildern und Videos. Sogar das Hochladen mehrerer Bilder von einem Android-Telefon funktioniert einwandfrei!
Allerdings wären einige Anpassungen erforderlich, hauptsächlich zur Vereinfachung der Benutzeroberfläche. Beispiele, nicht in einer bestimmten Reihenfolge der Wichtigkeit:
-
Die Gesamtanzahl der Beiträge eines Nutzers nicht anzeigen – dies soll verhindern, dass neue Mitglieder eingeschüchtert werden.
-
Die Bearbeitung von Beiträgen durch den Nutzer nach einer bestimmten Zeit blockieren (aktuell stellen wir dies auf 2 Stunden ein) – dies soll eine Art von Trollen verhindern, das in diesem Bereich nicht ungewöhnlich ist.
-
Ein Bereich für Kleinanzeigen wäre schön, mit einer Möglichkeit, für die Anzeige zu bezahlen (PayPal). Ich bin mir bewusst, dass dies aufgrund der Konfiguration der Preisstruktur, des Zahlungslinks usw. nicht trivial ist.
-
Das Jahr im Datum des Beitrags deutlich hervorzuheben.
-
Die Möglichkeit für Administratoren, zu einem Benutzer zu gehen und zu sehen, wer sonst noch unter derselben Browser-Installation aktiv ist (im Wesentlichen nur Cookies). Ich sehe, dass Discourse dies bereits bietet, aber basierend auf der IP-Adresse, was heutzutage nicht effektiv ist (viele Menschen nutzen mobile Daten, insbesondere diejenigen, die mehrere Identitäten verwalten wollen). Ich habe diesen Thread gelesen:
Handling trolls with multiple accounts over VPNs - #18 by ljpp
und andere, also haben offensichtlich viele andere diesen Weg bereits beschritten, und es gibt keine Lösungen für jemanden, der mit VPNs usw. clever umgeht; sie entlarven sich meist schließlich durch ihren Schreibstil oder durch das Posten von etwas wirklich Hässlichem, was dann zu einem Bann führt. Ich würde auch vorschlagen, dass das Erkennen desselben Passwort-Hashes ein Vorteil wäre, da viele Menschen dasselbe Passwort für alle ihre Charaktere verwenden
-
Für Administratoren eine einfache lineare Beitragsliste, die eine sehr schnelle Überprüfung der letzten x Beiträge auf einem Telefon ermöglicht. Ich stelle mir vor, dass dies mit etwas Code, der direkt auf die Datenbank zugreift, auf einer Subdomain umgesetzt werden könnte. Innerhalb dieser Liste sollten Lösch- und Bann-Buttons vorhanden sein, damit jemand, der etwas Hässliches postet (leider auf Foren nicht unbekannt), schnell entfernt werden kann.
-
Dies ist möglicherweise bereits vorhanden, soweit ich sehe: Administratoren können ausgewählte (oder alle) Beiträge aus einem Thread in einen anderen Thread zusammenführen, wobei die Beiträge im Zielthread in der richtigen chronologischen Reihenfolge landen. Ich bin mir bewusst, dass dies Links zu Beiträgen brechen kann, es sei denn, der Link ist einzigartig für die Site (z. B. die Beitragsnummer in der Datenbank, nicht die Beitragsnummer im Thread).
-
Generierung einer CSV-E-Mail-Liste durch Administratoren für alle, die sich innerhalb der letzten 12 oder 24 Monate angemeldet haben. Wir haben festgestellt, dass das Versenden von E-Mails an ältere (mehr veraltete) Personen die Wahrscheinlichkeit einer Schwarzeintragung (RBL usw.) stark erhöht, obwohl die Mailing (meist über Treffen, ein paar Mal pro Jahr) langsam durchgeführt wird, nur 1 E-Mail pro Minute, um das Risiko zu minimieren (wir blockieren in der Mailing auch alle bekannten Einweg-Adressen, z. B. sharklasers.com).
-
Eine Benutzereinstellung im Profil eines Nutzers, um festzulegen, ob diese E-Mails empfangen werden sollen, zur Einhaltung der DSGVO.
Ich habe gerade den Thread hier über die DSGVO gelesen. Soweit ich in Großbritannien verstehe, hat ein Poster kein Recht, die Löschung seiner Beiträge zu verlangen. Er kann seine Anmeldedaten entfernen lassen. Ich frage mich, ob Discourse in dieser Hinsicht in irgendeiner Weise zusätzlich anfällig ist. Auf unserem Forum verwendet ohnehin fast jeder einen Spitznamen.
-
Die Möglichkeit für Administratoren, private Nachrichten (PMs) zu lesen. Dies ist unerlässlich, da viele Spammer sich anmelden und nur PMs senden, keine Beiträge posten. Wir würden nichts davon erfahren, es sei denn, jemand beschwert sich, aber viele neue Anmeldungen sind verdächtig (aber nicht eindeutig), also beobachten wir sie eine Weile … Zum Beispiel haben wir eine Länder-Einstellung im Benutzerprofil, die während der Anmeldung angegeben werden muss, und jemand, der dort Deutschland angibt, aber eine thailändische IP-Adresse hat, ist wahrscheinlich unseriös, aber es könnte auch ein Deutscher in Thailand sein!
-
Eine Länder-Einstellung für den Standort des Benutzers, die bei der Anmeldung erzwungen wird (ich bin mir bewusst, dass sie dort angeben können, was sie wollen).
Ich bin mir bewusst, dass bei Code-Änderungen das Anwenden von Updates schwierig oder unmöglich sein könnte …
Verdächtige Anmeldungen sind ein echtes Problem. Ich schätze derzeit, dass 10–20 % der Anmeldungen verdächtig sind. Wenn also nichts unternommen wird, wird man in Zukunft viele Probleme bekommen. Das übliche Verhalten ist, sich anzumelden, eine Woche zu warten und dann das Forum mit Spam zu überfluten.
Leider weiß ich nichts über Ruby. Ich habe ein wenig PHP gemacht. Meine IT-Expertise ist allgemeiner: POP- und SMTP-Server, VMs, VPNs, FTP, SPF, DKIM, Router-Konfigurationen. Einfaches HTML, aber kein CSS … Meine alte IT-Expertise liegt in der Hardware und Software eingebetteter Systeme (Assembler und C). Der Mann, der die ursprüngliche Software geschrieben hat, bietet an, bei der Migration der Datenbank zu helfen. Ich habe einige Kontakte, die andere Teile übernehmen können, aber derzeit keine direkte Ruby-Expertise … Ich habe einige Sites auf einem Linode-Server laufen, der sich als sehr zuverlässig erwiesen hat, sodass dies die #1-Wahl für das Hosting wäre.
Vielen Dank im Voraus, dass Sie dies bis hierher gelesen haben, und vielleicht werfen Sie ein paar Hinweise ein, wie viel davon bereits vorhanden ist und wie viel Arbeit es wäre, den Rest oder etwas Ähnliches umzusetzen ![]()