Stefan Kalscheuer

Sch?n, dass ich helfen konnte.

Transparenterer Behandlung von internationalen Domains habe ich mir dennoch auf die TODO Liste für die kommenden Versionen gesetzt. Insofern danke für den Hinweis.

Gru0,
Stefan

Hi nochmal,

mittlerweile hatte ich Gelegenheit, mir das ganze mal anzuschauen.

Stand jetzt (Blacklist 1.4.4) kann ich die ASCII-Form der o.g. Domain (xn—-ctbigni3aj4h.xn--p1ai) eintippen und diese wird auch sauber herausgefiltert.
(Testinstallation: nginx 1.15, PHP 7.2.9 inkl. “intl” Paket)

Was aktuell nicht funktionieren, da es von der Validierung abgewiesen wird, ist die internationale Form direkt einzutippen, also soetwas wie “пример.ru” (“Beispiel” auf russisch – will ja nicht unn?tig Werbung für irgendwen machen).

Diese werden aber nicht in der Blacklist-Tabelle übernommen.

Was genau meist du damit? Alao welchen Text hast du probiert, wo einzutragen?

Gru?,
Stefan

Hi Christian,

das ist weniger ein Zeichensatzproblem, als vielmehr ein Konfikt mit internationalen Domain Namen (IDNA2008). Aber über die Begrifflichkeiten wollen wir nicht streiten.

Ich nehme an, du nutzt den einfachen Domain Filter ohne regul?re Ausdrücke? Dann kann ich mir die Ursache gut vorstellen, das w?re ein l?sbares Problem.

Kannst du mir verraten, welche PHP Version und welcher Webserver bei dir zum Einsatz kommen? Das Verhalten ist nicht bei allen einheitlich und damit lie?e sich ein realistischer Testfall aufbauen.

Gru?,
Stefan

Hi,

eine offensichtliche Erkl?rung w?re, dass deine Seite tats?chlich oft auf entsprechenden Webseiten verlinkt ist… Da du hier fragst, lautet die realistischere Antwort aber Referrer-Spam.

Es gibt verschiedene Herangehensweisen, um das Problem zu bek?mpfen.

• Statify bietet die M?glichkeit, die Kommentar Blacklist zu nutzen, dazu einfach “Ignoriere Tracking für Referrer, die in der Kommentar-Blacklist hinterlegt sind” aktivieren.
• Es gibt eine Erweiterung Statify Blacklist (Disclaimer: ich bin der Autor), um die Eintr?ge manuell, zeitgesteuert oder auch live zu filtern.
• Filterung/Umleitung der Anfragen auf Server-Ebene

Meinen Beobachtungen nach ist der Anteil der Spam-Eintr?ge bei “Seitenz?hlung via JavaScript” etwas geringer als ohne, da einige Spam-Bots nach wie vor nur die ursprüngliche Seite aufrufen und den asynchronen JavaScript Aufruf nicht mitmachen. Falls das nicht aktiv ist, w?re es auch schonmal ein (wenn auch vllt. kleiner) Schritt.

Gru?,
Stefan

Ungecachte Seiten sollte es eigentlich nicht geben

Beim Durchklicken habe ich schon eine Hand voll Seiten mit Erst-Ladezeiten >1s gefunden, die erst beim zweiten Aufruf <200ms lagen und den Cache-Kommentar in HTML enthielten. Normal, sofern nicht 100% der Seiten vorgeneriert werden und Caches nie ablaufen.

Die Statify-Parameter in der URL brechen das Coaching auf (würde ja auch sonst nicht funktionieren), daher ist nur ein Vergleich mit der ungecachten Seite ohne Statify wirklich aussagekr?ftig.

Grunds?tzlich sollte man (wir) aber auch nochmal sehen, ob man noch früher reinkommt, um überflüssige Rechenzeiten anderer Plugins zu unterbinden (die 1-2s dreht der Server ja vermutlich nicht nur D?umchen). Insofern danke für den Ansto?.

Hi Madd,

leider hatte ich bislang kein Glück, das Problem auf einer mir zug?nglichen Seite nachzustellen.

Hast du die M?glichkeit zu prüfen, wie hoch die Ladezeit für die Startseite ohne Caching Plugin ist? W?re wichtig, um eine Vorstellung zu bekommen, in welcher Gr??enordnung wir uns auf dem System überhaupt bewegen.

Statify kommt als Plugin mit S relativ weit hinten in der Liste, daher w?re es nicht auszuschlie?en, dass ein anderes Plugin die Ladezeit verursacht, welches vorher an der Reihe ist. Ohne o.g. Vergleichswert aber auch nur Spekulation.

Gru?,
Stefan

Nachtrag:
Ich habe mich gerade mal durch die Seite geklickt und einige, bislang offenbar ungecachte Seiten entdeckt, Ladezeit mitunter bis zu 2.5s (https://www.abenteuer-brettspiele.de/top-listen/top-10-brettspiele-2018-vorschau)
Das spr?che dafür, dass derartig lange Ladezeiten bei dir leider normal sind. Selbst aus dem Cache fallen zum Teil 200ms und mehr TTFB raus.

• This reply was modified 6 years, 7 months ago by Stefan Kalscheuer.

Hi carbeck,

Reason is not the JS capability of these bots, but their user agent strings.

Statify comes with a default filter that whitelists Windows, Linux, iPhone, etc.
The mobile bots however match this to force mobile display instead of desktop version.

Mozilla/5.0 (iPhone; CPU iPhone OS 8_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12B411 Safari/600.1.4 (compatible; YandexBot/3.0; +https://yandex.com/bots) — Indexing robot.

This behavior should probably be changed in future versions to a more refined blacklist.

Currently the only chance is a custom skip hook or a blacklist plugin to filter their IP subnet. (my blacklist extension does not feature user agent filter either at the moment)

Regards,
Stefan

Hallo vilmoskoerte,

dein System verwendet scheinbar eine MySQL InnoDB ohne die large_prefix_extension. Damit k?nnen keine Indizes auf referrer und target angelegt werden, da diese mit 255 Zeichen (je 4 Byte) zu gro? sind.

Davon ausgehend, dass es nicht dein eigener DB Server ist, wirst du auf die Einstlelung wahrscheinlich keinen Einfluss haben.

Workaround: Entferne die Keys.
* Gehe dazu auf Plugins -> Editor
* Oben rechts Statify w?hlen
* Rechts die Datei inc/class-statify-table.php w?hlen
* Zeilen 69 und 70 l?schen:
KEYreferrer(referrer)
KEY target (target)

Nachteile: Leichte Performance-Einbu?en im Admin-Interface, wenn du nicht gerade mit Millionen Besuchern oder jahrelanger Statistik arbeitest, vermutlich kaum spürbar.

Gru?,
Stefan

• This reply was modified 6 years, 9 months ago by Stefan Kalscheuer.
• This reply was modified 6 years, 9 months ago by Stefan Kalscheuer.

Hi SebH,

Statify uses home_url('/', 'relative') to generate the link requestes from JavaScript, so the call should be protocol-agnostic.

Could you please provide some details on your environment (WP- & Plugin-Version, active cache, default site URL, …)?

And please check the statify breadcrumb we’re placing the URL in. Should look something like this:
<div id="statify-js-snippet" style="display:none" data-home-url="/"> </div>
(data-home-url is subject of interest)

Cheers,
Stefan

• This reply was modified 6 years, 9 months ago by Stefan Kalscheuer.

Hallo Tobias,

ich habe die Vorschl?ge zum 1.5 Milestone hinzugefügt (konkreten Zeitplan kann ich momentan leider nicht versprechen).

Vielleicht ist ein flexibles System wie das Tag-System für die einzelnen Bestandteile gut, sodas diese kombiniert werden k?nnen.

Da wird man noch einmal etwas Hirnschmalz reinstecken müssen. Immer eine Gratwanderung mit der Datensammlung und es braucht einen sinnvollen Einstieg, das m?chte man eher nicht mehr von Null auf konfigurieren ??

Jedoch wei? ich nicht welche Stichworte ich dort einfügen sollte, da ich ja sonst kein Tracking nutze.

Ich habe meine (Domain-)Listen bisher durch das aufgebaut, was Statify mir geliefert hat. Referrer werden ja mit gespeichert und wenn man das Limit für die “Bestenliste” entsprechend hoch setzt, bekommt man ein Gefühl für das, was kommt.

Aber ja, das ist Zusatzarbeit, ein sinnvoller Default macht den Einstieg einfacher. Bei Domains gibt das blo? schnell einen Pranger-Effekt (w?re mit der geplanten Keyword-Erweiterung atürlich entsch?rft).

Gru?,
Stefan

Hallo Tobias,

im Gegensatz zu ASB hat dieses Plugin leider vergleichsweise wenige Erkennungsmerkmale. Ein Kommentar bietet wesentlich mehr Angriffsfl?che über den Inhalt, also Stichwort-Filter, E-Mail Adressen und zuletzt die interne IP-Blacklist. Hier haben wir im Grunde nur HTTP Header.

Korrigiere mich, wenn ich es falsch verstanden habe, aber du scheinst hier auch zwei Aspekte zu vermischen.

1. Die vorgeschlagene Blacklist:
Die von dir verlinkte Blacklist bringt gegen Referrer-Spam zumindest meiner Erfahrung nach so gut wie garnichts, da hier eher selten Werbung für Finanz-, Pharmazie- oder Rotlichtgewerbe gemacht wird, viel mehr SEO-Angebote zweifehlafter Herkunft. Man müsste sie in jedem Fall anpassen.

Einen Filter gegen die WP globale Blacklist (Option “blacklist_keys”) bringt Statify selbst mit.

Die Frage nach dem Sinn kannst du dir selbst beantworten. Schau dir die statify Tabelle in der Datenbank an oder lass dir alle Referrer im Widget ausgeben. Wie hoch ist der Anteil der Referrer, die Stichw?rter aus der genantnen Liste enthalten und damit wegfallen würden?

Den Referrer-Filter grunds?tzlich als Stichwort-Filter auszulegen und nicht als Domain-Filter, ist aber eine realistische Idee. W?re das für dich eine Option, neben Domain/Regex einfach eine Stichwort-Liste hinterlegen zu k?nnen?

2. IP Adressen:
Hierfür müsste das Plugin lernf?hig sein und IP Adressen speichern. Gegen diese Liste müsste dann bei jedem Seitenaufruf geprüft werden, was abh?ngig von der Gr??e dieser Liste aus Performance-Sicht nicht unbedingt wünschenswert ist (zumindest bei Nicht-JS Tracking). Einzige Alternative, man bricht mit dem Statify Grundprinzip und speichert die Adressen – wenn auch nur für ein paar Minuten – um das ganze Asynchron zu gestalten.

Sollte dir eine Verknüpfuing mit der IP-Sammlung von ASB vorschweben, ist letztlich die Frage, was man genau aus der Statistik filtern m?chte. Also im Grunde die Frage “ist ein Menschm, der einen Spam-Kommentar hinterl?sst ein Besucher i.s.d. Zugriffsstatistik”. Bei Kommentar-Spam wird ja nicht zwischen Bot und Mensch unterschieden.

Abgleich mit externen Datenbanken scheidet zumindest im Rahmen dieses Plugins für mich grunds?tzlich aus. Sowohl aus Datenschutz- als auch aus Performance-Gründen.

Wenn auf Webcrawler aus bist, die sich als “echter Browser” tarnen und damit nicht automatisch rausfliegen, die IP-Netze der gr??eren Betreiber sind idR. kein Geheimnis…

Gru?,
Stefan

Version 1.6.3 ist vor rund einer Stunde erschienen, welche die hier mehrfach best?tigte L?sung beinhaltet.

Wir empfehlen ein Update von 1.6.1/1.6.2 auf die neue Version zur Wiederherstellung der Funktionalit?t.

Gru?,
Stefan

Hi,

Würde die Minimal-L?sung, Ersetzen des Zeilenumbruchs zwischen type und src durch ein Leerzeichen, dein Problem akut beheben?

Das w?re ja fix erledigt, da aktuell ja ein Bugfix auf das Release wartet…

Ansonsten müssten wir schauen, wann das einzuplanen w?re.

Gru?,
Stefan

@arkoudi

na dann mal her mit der L?sung bitte

Wir sind noch dabei, die L?sung zu testen.
Das Problem ist leider nicht ganz einfach zu reproduzieren, da es nur mit wenigen PHP Konfigurationen auftritt.

Wer etwas experimentierfreudig ist, kann die inc/class-statify-frontend.php durch diese hier ersetzen, dann müsste der Fehler weg sein.
https://github.com/pluginkollektiv/statify/blob/hf-filterInputVar/inc/class-statify-frontend.php

Sobald das Fix best?tigt ist, geht zeitnah ein Update raus.

Gru?,
Stefan

Vielen Dank @carbeck ! Das best?tigt unsere Vermutung und gibt es zum Glück auch eine L?sung ??

@inconetmedia
Vermutlich ein anders Problem, schauen wir uns auf jeden Fall mit an, danke für den Hinweis.

Gru?,
Stefan