Kontaktformular und Gästebuch für Gäste gesperrt?

[Timbalu]

Standard-Captchas sind nicht barrierefrei und stellen zudem selbst für einfach gestrickte Spam-Bots kein Hindernis da. Hinzu kommt, dass die Umsetzung quasi „konstruktionsbedingt“ fehleranfällig ist.Ich glaube, jeder Internetnutzer hat schon mal vor einem Captcha gesessen und gerätselt, was die Grafik wohl anzeigen mag, und/oder mehrere Fehleingaben erzeugt.

Nicht Barrierefrei? Stimmt!
Ansonsten: einfacher reload bringt immer neues Captcha.
Man darf die Dinger nicht immer so verteufeln. Sie erfüllen oft genug und manchmal über Jahre treu ihren Dienst. Ich habe das Gästebuch als Captcha-Beispiel über mehrere Jahre laufen lassen ohne je ein einziges Spam zu bekommen. Anderes installieren es und schwupps haben sie zig Dinger drin.... Es gibt halt so'ne und so'ne Bots.

Man muss halt immer dran bleiben. Das ist bei bayes wohl auch so.

[Timbalu]

Moderationsschlange = Moderationswarteschlange

tztztztzzzzzzzzz!
Doch die hats, aber bisher nur wenn in config explizit gesetzt.

Wenn moderiert, dann wird $ca['moderate_comments'] auf true gesetzt. Dann sollte das Gästebuch den Eintrag zur Moderation einreihen.

Oh ja das ist einbaubar, I assume... (Robben Pfosten, grrrrrr bin leicht abgelenkt.)
Ist das 'moderate_comments' erst erhältlich wenn bayes installiert ist?

[Timbalu]

Das ist so eine Art Abschottungschalter für Blogbetreiber, die sicehrstellen wollen dass nicht gespammt werden kann - und wenn, dann nur von registrierten Gästen, die man dann abmahnen kann

Ach ok, ich verstehe. Unter diesem Gesichtspunkt verstehe ich das natürlich auch als Notwendigkeit für jeglichen Gäste-input. Wird das bei der Option im AddUser Plugin auch deutlich?

Hi Garvin

Jetzt weiß ich wieder, warum mir das mit dem AddUser Abschottungsschalter so komisch vorkam....
Im Spamschutz Plugin (serendipity_event_spamblock) gibt es diese Option:

Code: Select all

Notfall-Blockade von Kommentaren
 Übergangsweise Kommentare zu allen Einträgen verbieten. Nützlich, wenn das Blog unter andauerndem Spam-Beschuss leidet.

Ist das dasselbe und ist es beabsichtigt, dass beide anscheinend die gleiche Funktionalität bieten? Wird das irgendwo deutlich?

[Timbalu]

Hi Garvin, Malte

==== Hirn knnnoooorrrrkkks 2. Teil ====

Edit:
Ich nehme die Verknotungen des 2. Teils zurück. Die haben sich geklärt....

Edit2:
Naja, doch noch nicht ganz.

Warum wirft der Rückgabewert ['moderate_comments'] immer true, wenn ['allow_comments'], also die Captchas, ebenfalls true zurückgibt?

Ich nahm dabei an, dass moderate_comments nur dann auf true gesetzt wird, wenn irgendwelche Stopwörter einer sofortigen Veröffentlichung entgegenstehen. Oder schleift das nur eine generelle Spamblock Config Option durch?
Die Behandlung von per API übermittelten Kommentaren steht auf keine.

[onli]

Ich nahm dabei an, dass moderate_comments nur dann auf true gesetzt wird, wenn irgendwelche Stopwörter einer sofortigen Veröffentlichung entgegenstehen. Oder schleift das nur eine generelle Spamblock Config Option durch?

Sollte nicht passieren. Da greift vll wirklich etwas anderes. moderate_comments === true bedeutet ziemlich sicher, dass ein Plugin den Kommentar moderieren lassen will.

[Timbalu]

Sollte nicht passieren. Da greift vll wirklich etwas anderes. moderate_comments === true bedeutet ziemlich sicher, dass ein Plugin den Kommentar moderieren lassen will.

hmmmm, guestbook ohne approval, kein bayes, nur spamblock plugin:

Code: Select all

Mein
viagra gold casino test
mit approved false

und

Code: Select all

Mein test
mit approved false

gibt, solange captchas stimmen, immer moderate_comments (true) zurück.

Code: Select all

ca= Array
(
    [id] => 0
    [allow_comments] => 1
    [last_modified] => 1298650346
    [timestamp] => 10
    [moderate_comments] => 1
)

Übrigens geht das Ganze sowieso nur, wenn $ca im fake call kein moderate_comments mit in den hook schickt.

[yellowled]

Ansonsten: einfacher reload bringt immer neues Captcha.

Ich prophezeie, dass 75% der Besucher nach dem dritten Reload sagen: „Kommentier ich halt nicht.“ -- wenn sie überhaupt dahin kommen, dreimal zu reloaden. (Du vergisst, dass es Leute gibt, die das Web anders nutzen als mit Bildschirm und Maus.)

Sie erfüllen oft genug und manchmal über Jahre treu ihren Dienst.

Nenn mir bitte eine einzige Sache, die ein Captcha leistet und Spamschutz Bayes nicht.

YL

[Timbalu]

Sie erfüllen oft genug und manchmal über Jahre treu ihren Dienst.

Nenn mir bitte eine einzige Sache, die ein Captcha leistet und Spamschutz Bayes nicht.

Da du bitte benutzt, gibt es auch eine Antwort.
Ich brauche kein entweder oder, sondern ein sowohl als auch. Mehr wollte ich nicht sagen, als ich gegen die Verteufelung von Captchas sprach. So long.

[garvinhicking]

Hi!

Aaaaalso, dann versuchen wir doch mal etwas Licht zu scheinen.

Zum einen: Die "Notfall Blockade" ist etwas anderes. hier wird ALLEN Besuchern verboten Kommentare zu schreiben. Die adduser-Option ist nur dafür da, Feedback auf REGISTRIERTE Besucher zu beschränken.

Nun zu allow_comments/moderate_comments.

allow_comments setzt s9y eigentlich bei Blogartikeln abhängig davon, ob zum jeweiligen Blogartikel die "Kommentare erlaubt" sind. Wenn ein Plugin das macht, gibt es normalerweise ja kein Kommentar zueinem Blogartikel sondern etwas anderes. Damit die Spamfilterungsmaßnahmen dann aber trotzdem daran rumkauen können muss allow_comments immer auf TRUE gesetzt sein, damit das was ein Plugin schickt weitergelitten wird.

moderate_comments ist analog dazu die Option, ob Blog-Kommentare der Moderation bedürfen. Auch das gilt für Plugindaten eigentlich nicht, daher wird immer FALSE übermittelt (also "Eintrag soll gepostet werden, Moderation nicht notwendig"). Moderation greift ja eh nur für Blogeinträge.

Da die weitere Verarbeitung vom Spamblockplugin auf blog-Einträgen basiert, greift sich das diese Variable um damit als eine Art Rückgabewert festzulegen, ob ein Kommentar geblockt wurde.

Hilft das irgendwie? Ich bin verwirrt ob der konkreten Frage.

Grüße,
Garvin

[Timbalu]

Hi Garvin

Zum einen: Die "Notfall Blockade" ist etwas anderes. hier wird ALLEN Besuchern verboten Kommentare zu schreiben. Die adduser-Option ist nur dafür da, Feedback auf REGISTRIERTE Besucher zu beschränken.

So machts natürlich auch Sinn. Danke.

Nun zu allow_comments/moderate_comments.

Allow_comments. Verstehe.

Die Spamfilterungsmaßnahmen via moderate_comments werden allerdings doch ausgeliefert, wenn, wie im Gästebuch oder Kontaktformular, der fake call zb. so

Code: Select all

        $ca = array(      
                    'id'                    => 0,
                    'allow_comments'        => true,
                    'last_modified'         => time(),
                    'timestamp'             => 10
                    );

in den hook geschickt wird.

Dies wirft, je nach Einstellung des Spamblock Plugins,
$serendipity['csuccess'] = 'moderate' und
$serendipity['moderate_reason'] = Moderation nach X Tagen zurück.
Und es setzt 'moderate_comments' auf true.

Umgehe ich Moderation nach X Tagen mit einem geeigneteren Timestamp

Code: Select all

                    'timestamp'             => strtotime("-1 day" ,time())

greift das von dir geschilderte Verhalten und 'moderate_comments' springt nicht auf Plugins Content an.

Damit kann man das Entry Spam-Feintuning über Moderieren (von Spamblock-bayes) - aufgrund von SPAM-Stopwörtern im ansonsten durchgewunkenen Text - auch nicht richtig in den genannten Plugins nutzen. Schade irgendwie.
Hilft diese Erklärung die Verwirrung zu beenden ?

[garvinhicking]

Hi!

Korrekt, das Moderieren-Feature kann man so nicht ohne weiteres nutzen; dafür müsste es dann eine moderationsqueue für z.b. Gästebucheinträge geben und man müsste das Bayes-Pluigin dann auch darauf ansetzen, das könnte aufwändig sein.

Grüße,
Garvin

[Timbalu]

Hi Garvin

Nachdem ich damit unzufrieden war und ein bißchen herumgespielt habe, denke ich eine einfache Lösung gefunden zu haben, nachdem ich feststellte, dass die Schlange trotzalledem durchlaufen wird.

Spamblock Plugin ~ Zeile 1060 - setze unterhalb von

Code: Select all

 // Filter Content
 $filter_bodys = explode(';', $this->get_config('contentfilter_words', $this->filter_defaults['words']));

diese zwei Zeilen (merge aus filter authors und bodys ist geeigneter für Plugincontent),

Code: Select all

 // check for plugin entry content by $addData['filter_by'] and merge some stopword arrays
 $filter_bodys = ($addData['filter_by'] == 'plugin' ? array_merge((array)$filter_authors, (array)$filter_bodys) : $filter_bodys);

dann muss man aus dem Gästebuch nur noch ein

Code: Select all

'filter_by'   => 'plugin',

mit ins Rennen schicken (oder nutzt gleich 'source')

Code: Select all

        $commentInfo = array(      
                    'type'        => 'NORMAL',
                    'source'      => 'guestbookform',
                    'filter_by'   => 'plugin',
                    filter felder blah blah
                    );

und schon hat man

Code: Select all

IN moderate
CSuccess: moderate - REASON: Spamschutz: Ungültiger Kommentar! (Wortfilter für Inhalt: poker)
ca=

Array
(
    [id] => 0
    [allow_comments] => 1
    [last_modified] => 1298898770
    [timestamp] => 1298812370
    [moderate_comments] => 1
)

[Timbalu]

Die Frage bleibt natürlich, Malte, ...
ob bayes seine erlernten Daten - speziell spam - in irgendeiner Weise per hook wieder an das spamblock plugin zurückgibt, so dass die dort ausgewerteten Stopword-Daten zB in filter_bodys und filter_authors von bayes kompletiert und ergänzt werden, oder vice versa?

Oder läuft das komplett als unabhängige Ergänzung des Spamblock Plugins und müsste eventuell auch noch ergänzt werden, um es nutzen zu können?

[onli]

Bayes ist komplett unabhängig, da wird nichts vermischt :)

[Timbalu]

Danke, gut zu wissen, Malte.
Dann kann ich - wenn Garvin meinen Vorschlag in dieser oder ähnlicher Weise für das Spamblock Plugin aufnimmt - eine neue Version mit entsprechendem Hinweis herausgeben.