Trackbacks und https (keine Eingangserkennung)

[bernd_d]

Kann das vorher genannte Zeug mal bitte für jemanden übersetzen, der nix mit Goethe zu tun hat?

Scheinbar bekomme ich seit dem Update auf 1.7.2 (zumindest glaube ich, es auf den Zeitraum eingrenzen zu können) keine internen Trackbacks mehr zugewiesen. Beim Senden der Trackbacks steht zwar im Log

Code: Select all

• Überprüfe https://bernd.distler.ws/archives/1315-Cullmann-NanoMax-200T.html auf mögliche Trackbacks ...
Sende Trackback zu URI https://bernd.distler.ws/comment.php?type=trackback&entry_id=1315 ...
• Trackback erfolgreich!

aber im Backend kommt nix an

[Timbalu]

Auch Schopenhauer würde fragen: Wie sind denn deine Spamblock Plugin Trackback Einstellungen?

[bernd_d]

serendipity_event_spamblock_bee

• Honeypot ja
• Captchas ausgeschaltet

serendipity_event_spamblock_bayes

• Spambehandlung: manuelle Grenzen
• Moderation: 40 %
• Abweisung: 90 %
• (haufen anderes Zeug, dass nicht relevant sein dürfte)

serendipity_event_spamblock

• Trackbacks/Pingbacks: IP Validierung: moderieren
• Trackback/Pingbackmoderation nach wievielen Tagen erzwingen: 30
• IP-Block Intervall: 1
• Was soll mit auto-moderierten Trackbacks/Pingbacks passieren?: Moderieren
• Behandlung von per API übermittelten Kommentaren: keine
• Trackbacks/Pingbacks: URLS prüfen: Ja
• Direktkommentare verbieten? (XSRF-Schutz): Nein
• Was soll mit auto-moderierten Kommentaren passieren?: moderieren

[Timbalu]

Das sieht im Spamblock eigentlich doch gut aus. (Ich habe fast die selben Einstellungen und mein lokaler Trackback wird als zu Moderieren in der comment list aufgeführt)

Ich würde daher sagen, BEE Captcha an und BAYES hinter Spamblock rücken!
Wahrscheinlich filtert dir Bayes die internen Trackbacks weg. Schau mal in den Papierkorb bzw die SPAM-keys und eventuell zur Sicherheit in dein Reject-Log-Logging. Da müsste dein Trackback ja als abgewiesen oder ähnliches drinnen stehen.

[yellowled]

Ich würde daher sagen, BEE Captcha an und BAYES hinter Spamblock rücken!

Die „empfohlene“ (von Grischa) Reihenfolge – ohne, dass ich jetzt zitierfähig wäre, warum genau – ist Biene – Bayes – Spamblock. Genau das Setup funktioniert z.B. bei mir seit Monaten wunderbar, auch mit internen Trackbacks.

YL

[bernd_d]

Ich habe jetzt in allen Plugins das Logging aktiviert und einen Test-Trackback erstellt, aber es kommt nichts an und auch in den Logs taucht nichts auf.

Kann es vielleicht sein, dass es nicht an den Einstellungen/Plugins liegt, sondern möglicherweise daran, dass ich das https-Protokoll verwende und da irgendwo im Core bzgl. Trackbacks etwas falsch erkannt wird und deshalb nicht verarbeitet werden kann?

Am Alter der Beiträge scheint es nicht zu liegen, denn ich habe jetzt auch mal einen Pingback auf einen neuen/aktuellen Beitrag gesetzt und auch dort kommt nichts in der Datenbank an, obwohl beim Senden die Erfolgsmeldung kommt.

In dem Fall sollten wir das Thema vielleicht absplitten, falls es sich um einen Bug handelt.

[Timbalu]

Das mag sein, dass das auch mit den internen Trackbacks funtioniert.

Zur Reihenfolge dieser SPAMschutz Plugins habe ich aber ganz andere Erfahrungen gemacht, siehe http://board.s9y.org/viewtopic.php?f=4&t=19431 und würde deshalb jetzt immer zu dieser Reihenfolge raten. Sie ist auch einfach logischer! Man muss vermeiden, dass sich Bayes zu schnell vollspammt und hat damit zu tun, ob autolearning aktiv ist und zB viel API generated Spam ankommt.

[Timbalu]

Kann es vielleicht sein, dass es nicht an den Einstellungen/Plugins liegt, sondern möglicherweise daran, dass ich das https-Protokoll verwende und da irgendwo im Core bzgl. Trackbacks etwas falsch erkannt wird und deshalb nicht verarbeitet werden kann?

Möglicherweise. Ich hatte vorhin auch schon mal kurz darüber nachgedacht.
Kannst du das nicht mal für einen Moment abschalten und interne Trackbacks testen, so dass man definitiv in dieser Richtung suchen kann?

[bernd_d]

OK, ich konnte das Problem eingrenzen, nachdem ich die harte SSL-Umleitung deaktiviert habe...

Code: Select all

HTTPS -> HTTPS -> FAIL
HTTP -> HTTP -> OK
HTTPS -> HTTP -> OK
HTTP -> HTTPS -> FAIL

Jetzt dürfen die Programmierer ran

btw: Könnte das Thema einer der Moderatoren dann bitte abspalten? Handelt sich wohl definitiv um einen Bug beim Protokoll.

[bernd_d]

Ich habe jetzt mal ein paar Trackbacks von einer anderen Installation versucht und das Problem tritt genauso auf, wenn ein anderes Weblog einen Trackback auf die https-Url setzen will. Das ist natürlich besonders fatal

[onli]

Auf den ersten Blick sehe ich den Fehler nicht. Aber der Code ist zwar nicht absurd, aber auch nicht super zugänglich.

Bevor ich mich da jetzt mit Zertifikatgenerierung rumschlagen muss um das lokal testen zu können: Aktiviere doch bitte das Logging und probiere es nochmal. Dafür musst du nur die comment.php editieren und in Zeile 56 und 58 die Variablen $tb_logging bzw $pb_logging auf true setzen.

Wenn es ein Trackback ist sollte dann die Datei trackback2.log erstellt werden, bei einem Pingback die pingback.log.

[bernd_d]

Ich habe in einem Artikel die beiden URLs verlinkt (der zweite ohne s, abgeschickt aus dem https-Raum):

Code: Select all

https://bernd.distler.ws/archives/1385-Probleme-mit-Serendipity-und-https-URLs.html
http://bernd.distler.ws/archives/1379-erste-Gehversuche-mit-HDR-Fotos.html

pingback.log

Code: Select all

[14.08.2013 13:43] CONTENT_TYPE: application/x-www-form-urlencoded
[14.08.2013 13:43] HTTP_RAW_POST_DATA:

trackback2.log

Code: Select all

[14.08.2013 13:43] RECEIVED TRACKBACK
[14.08.2013 13:43] Array
(
    [type] => trackback
    [entry_id] => 1379
    [url] => http://bernd.distler.ws/archives/1386-ein-Test-mit-Ping-Trackback.html
    [title] => ein Test mit Ping-/Trackback
    [blog_name] => Bernds Rappelkiste
    [excerpt] => Hier steht nichts wichtiges, ich teste nur verschiedene Dinge mit diesem Link und auch noch dem Link hier
)

[14.08.2013 13:43] Match on /comment.php?type=trackback&entry_id=1379
[14.08.2013 13:43] ID: 1379
[14.08.2013 13:43] TRACKBACK TRANSCODING CHECK
[14.08.2013 13:43] TRACKBACK DATA: Array
(
    [title] => ein Test mit Ping-/Trackback
    [url] => http://bernd.distler.ws/archives/1386-ein-Test-mit-Ping-Trackback.html
    [name] => Bernds Rappelkiste
    [comment] => Hier steht nichts wichtiges, ich teste nur verschiedene Dinge mit diesem Link und auch noch dem Link hier
)
...
[14.08.2013 13:43] TRACKBACK STORING...
[14.08.2013 13:43] insert comment into DB
[14.08.2013 13:43] SQL: INSERT INTO serendipity_comments (entry_id, parent_id, ip, author, email, url, body, type, timestamp, title, subscribed, status, referer) VALUES ('1379', '0', '95.143.172.58', 'Bernds Rappelkiste', '', 'http://bernd.distler.ws/archives/1386-ein-Test-mit-Ping-Trackback.html', 'Hier steht nichts wichtiges, ich teste nur verschiedene Dinge mit diesem Link und auch noch dem Link hier', 'TRACKBACK', '1376480583', 'ein Test mit Ping-/Trackback', 'false', 'approved', '')
[14.08.2013 13:43] status: approved, moderate: false
[14.08.2013 13:43] Approving...
[14.08.2013 13:43] TRACKBACK SUCCESS

Wie man sieht, wird der erste Link mit https-Protokoll komplett ignoriert. Ich habe den Beitrag nochmal mit beiden Links auf das http-Protokoll erstellt, da werden beide Trackbacks korrekt erstellt.

[garvinhicking]

Hi!

Ist in einem PHP openssl mit drin&aktiviert? Das wird soweit ich mich erinnere benötigt um einen HTTPS-Request abzusetzen... Es spricht dafür dass dies nicht der Fall ist bei dir, wenn acuh andere https-Links nicht geöffnet werden können. Alternativ könnte es auch ein Firewallproblem sein dass ausgehende Requests auf Port 443 nicht durchkommken und nur Port 80 erlaubt ist?

Grüße,
Garvin

[bernd_d]

Ist in einem PHP openssl mit drin&aktiviert? Das wird soweit ich mich erinnere benötigt um einen HTTPS-Request abzusetzen...

Ich kann es zumindest in der Shell benutzt, vermute also, dass es auf dem uberspace verwendbar ist.

Nachtrag: php -m sagt, dass das openssl-Modul installiert ist. (war ein Hinweis von onli, dass man da gucken muss)

Es spricht dafür dass dies nicht der Fall ist bei dir, wenn acuh andere https-Links nicht geöffnet werden können. Alternativ könnte es auch ein Firewallproblem sein dass ausgehende Requests auf Port 443 nicht durchkommken und nur Port 80 erlaubt ist?

Keine Ahnung. Ich frage mal beim Support nach.

Antwort ist, dass ausgehende Verbindungen nicht reglementiert werden, nur eingehende. Da der Blog per HTTPS erreichbar ist, müsste das dann wohl auch korrekt gehen.

[garvinhicking]

Hi!

Mach mal ein einfaches test.php script mit:

Code: Select all

<?php
echo file_get_contents('https://bernd.distler.ws/archives/1385-Probleme-mit-Serendipity-und-https-URLs.html');

und führ das aus um zu sehen ob Du die Inhalte präsentiert bekommst, das wäre ein erster Schritt um zu testen ob die PHP SSL Wrapper theoretisch da sind.

Grüße,
Garvin