Jeden Tag werden ein Dutzend Spam-Konten mit der Kennzeichnung „Dieser neue Benutzer hat Profilinformationen eingegeben, ohne Themen oder Beiträge zu lesen“ markiert.
In zwei Jahren hatten wir 0 Fehlalarme.
Daher denke ich, dass wir diese Konten automatisch löschen könnten, wenn sie aus diesem spezifischen Grund markiert werden.
Optional könnte eine automatische E-Mail an den Empfänger vor der Löschung gesendet werden, in der erwähnt wird, dass das Konto automatisch gelöscht wurde, aber dass der Administrator per E-Mail über das Forum erreicht werden kann.
Ich habe mir Discourse Automation angesehen, aber es erlaubt dies nicht von Haus aus.
Wäre es möglich, ein Plugin mit Discourse-Automatisierungsmethoden zu programmieren, oder sollte es von Grund auf neu programmiert werden?
Oder gibt es einen einfacheren Weg, diesen endlosen Spam von unserer Überprüfungsliste fernzuhalten?
Ich probiere das also aus, ich werde die Webhooks verwenden, die ich noch nie zuvor benutzt habe.
Ich habe Use Discourse webhooks with PHP als Vorlage verwendet und es gibt Daten ordnungsgemäß an Discourse zurück.
Aber ich muss überprüfbare Spam-Elemente manuell erstellen (wie „Benutzer hat zu schnell getippt“ oder „Profil ausgefüllt, ohne einen Beitrag zu lesen“). Irgendwelche Ideen, wie das geht?
Erstellen eines Benutzers mit Insomnia, Ausfüllen seines Profils mit einem Akismet-Trigger, der eine Überprüfung auslöst.
Einige Prüfungen werden durchgeführt und der Benutzer wird automatisch gelöscht.
Die Überprüfungseigenschaften, damit das Skript eine Benutzerlöschung auslöst, sind:
Type: ReviewableAkismetUser, ReviewableUser oder ReviewableQueuedPost
Score > 0
Ich möchte keine Benutzer automatisch löschen, die von anderen Benutzern als @system markiert werden.
Hier ist das PHP-Skript, das ich verwende:
<?php
// Sofort die Authentizität der Anfrage überprüfen.
if (array_key_exists('HTTP_X_DISCOURSE_EVENT_SIGNATURE', $_SERVER)) {
$discourse_payload_raw = file_get_contents('php://input');
$discourse_payload_sha256 = substr($_SERVER['HTTP_X_DISCOURSE_EVENT_SIGNATURE'], 7);
// Aus Sicherheitsgründen konfigurieren Sie den Webhook mit einem Geheimnis in Discourse und setzen Sie ihn unten.
$discourse_payload_secret = '2J3tM5X4WYGkGp0tTkmu';
// Überprüfen Sie, ob die Anfrage von einem autorisierten Webhook gesendet wurde.
if (hash_hmac('sha256', $discourse_payload_raw, $discourse_payload_secret) == $discourse_payload_sha256) {
echo 'received';
}
else {
die('authentication failed');
}
}
else {
die('access denied');
}
// Bereiten Sie die Nutzlast für die Verwendung im PHP-Skript vor.
$discourse_json = json_decode($discourse_payload_raw);
$reviewable = $discourse_json->reviewable;
// Richten Sie die API-URL ein
$api_url = "https://discourse.canapin.com/review/$reviewable->id/perform/delete_user?version=0";
//$api_url = "https://discourse.canapin.com/review/$reviewable->id/perform/delete_user?version=$reviewable->version";
// Überprüfen Sie, ob die Eigenschaften "type" und "score" gültig sind
if (($reviewable->type == "ReviewableUser" || $reviewable->type == "ReviewableAkismetUser" || $reviewable->type == "ReviewableQueuedPost") && $reviewable->score > 0) {
// Richten Sie die Curl-Optionen ein
$options = array(
CURLOPT_URL => $api_url,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_CUSTOMREQUEST => "PUT", // Setzen Sie die Anfragemethode auf PUT
CURLOPT_HTTPHEADER => array(
"Api-Key: 6666666666666666666666666666666666666666666",
"Api-Username: system"
)
);
// Initialisieren Sie die Curl-Sitzung
$curl = curl_init();
curl_setopt_array($curl, $options);
// Führen Sie den API-Aufruf durch
$response = curl_exec($curl);
curl_close($curl);
// Dekodieren Sie die Antwort
$response_data = json_decode($response);
print_r($response_data);
} else {
exit;
}
?>
Auf einer Skala von 0 bis 10… Wie hässlich zuverlässig ist es, angesichts des Kontexts, in dem es funktionieren wird (0 False Positives in 2 Jahren für Discourse- und Akismet-Erkennungen)?
Ich habe ein paar Fragen zur Payload der Überprüfungsanfrage, die von Discourse ausgelöst wird, wenn ein Benutzer als potenzielles Spam-Konto erkannt wird.
Warum gibt es 2 Anfragen für 1 ReviewableUser mit minimalen Unterschieden zwischen ihren jeweiligen Payloads (die erste Anfrage ist links)?
Wenn ich manuell einen Benutzer (von Akismet erkannt) aus dem Überprüfungspanel lösche, wird der Webhook zur Überprüfung mit einer neuen Payload ausgelöst, die unter anderem Folgendes enthält: "user_deleted": false. Sollte dies nicht true sein?
In der URL https://discourse.canapin.com/review/355/perform/delete_user?version=0\", bezieht sich die “version” hier auf die “version”, die in der Payload gefunden wird? Sollte ich mich um diesen Parameter kümmern? Sollte er gleich dem version-Parameter der Payload sein?
Im aktuellen Zustand bin ich ziemlich zuversichtlich, dass das funktionieren wird (naja, meistens Intuition…) und wir potenzielle Probleme anhand der Webhook-Ergebnisse verfolgen können…
Oder die geprüften Elemente auflisten.
Aber hier gibt es ein Problem, das ich nicht lösen kann.
Manchmal sieht die Liste der geprüften Elemente so aus, ohne jegliche Informationen:
Nur zur Info: Ich habe dies ein paar Mal gesehen, und es war einmal ein Fehlalarm: ein vernünftiges und fürsorgliches neues Mitglied, das zuerst sein Profil ausgefüllt hat. Es kann also vorkommen.
Ja. Ehrlich gesagt hatte ich in diesem Zeitraum von mehr als zwei Jahren (soweit ich weiß) 1 False Positive.
Der Nutzer hat mich dann per E-Mail kontaktiert, die leicht auf der Website zu finden ist, falls ein Nutzer auf ein Problem stößt.
In meinem Fall und nach manueller Überprüfung Tausender von Nutzern wäre der Vorteil dieser automatischen Löschung meiner Meinung nach ziemlich offensichtlich, insbesondere da es sich um ein Nischenforum handelt – Nutzer, die sich wirklich für das Thema interessieren, werden uns kontaktieren, wenn sie Unannehmlichkeiten haben.
