Stefan Kalscheuer

Hallo Markus,

aktuell ist es nicht Konfiguration möglich und auch nicht vorgesehen. Ich habe für mein Erweiterungs-Plugin “Statify Blacklist” bereits die selbe Anfrage auf dem Tisch liegen, daher ist das Thema nicht ganz neu.

Länder lassen auch entweder durch Verarbeitung der IP Adresse oder (unzuverlässigen) Auswertung der Sprach-Header im Browser ermitteln. Dazu müsste aber eine GeoIP PHP-Erweiterung samt Datenbank installiert sein oder Statify seine eigene Datenbank mitliefern.

Die Alternative, Browser-Header, ist sehr ungenau (die Hälfte meiner Rechner z.B. leben in en-US und nicht de-DE und Spambots halten sich eh nicht an Regeln)

Stand jetzt müsste man die Logik selbst implementieren und über den Hook statify__skip_tracking einbinden.

Achtung Eigenwerbung:
Viel Spam lässt sich auch über Referrer Blackliste eliminieren. Entweder die eingebaute Kommentar-Blacklist oder selbst steuerbar über eine eigene Liste oder auch IP Subnetz-Filter mit der o.g. Erweiterung.

Gruß,
Stefan

Because it seems to happen periodically, I’d suspect a caching issue here. Both random subpages I’ve checked have timestamps between 1 and 3 hours ago, so pretty fresh, and tracking works as expected.

You might verify my theory if you got access to the server’s access logs.
WP AJAX requires a nonce to be transmitted for access to a certain action. Nonces are valid for 24h by default (not exactly, see codex link below for details on the tick structure). If an outdated nonce is used due to caching, the call to /wp-admin/admin-ajax.php results in error 403 instead of correct 204.

After quick analysis you’re using WP Fastest Cache, Autoptimize and finally the Cloudflare cache.

Autoptimize is out, because the nonce is placed in the site markup directly, so the aggregated caching time of WPFC and Cloudflare is crucial here.

If I’m correct, you can either adjust the caching times or increase the nonce lifetime: https://codex.wordpress.org/WordPress_Nonces (section “Modifying the nonce lifetime”).

Plugins requiring a “fresh” nonce usually do validate the age in custom logic, so in most cases, a (reasonably) longer time should not raise any problems.

Cheers,
Stefan

Ich bekomme keinen 400, sondern korrekt 204.

In der Netzwerkübersicht der Entwicklertools finde ich den Aufruf so:

Request URL: https://*****/wp-admin/admin-ajax.php
Request Method: POST
Status Code: 204
[…]
Form Data:
_ajax_nonce: ********** (normaler Hex-String)
action: statify_track
statify_referrer:
statify_target: /

Identisch für eine zufällige Unterseite. Getestet mit aktuellen Chrome 83 und Firefox ESR 68 (Linux) ohne Plugins mit initial leeren Caches.

Kannst du Details wie die oben genannten über deinen Fehlerhaften Aufruf machen? 400 am AJAX Endpunkt bedeutet ja für gewöhnlich dass eine ungültige Action übergeben wurde.

Hallo Christian,

ist JavaScript Tracking aktiv?

Wenn Ja:
Dann wird der Referer durch JavaScript im Browser ermittelt.

Die einfachste Erklärung wäre hier, dass es tatsächlich eine Umleitungen oder Links von der IP Adresse (also default vHost) auf deine Seite und diese werden auch aufgerufen. Das Verhalten der Header ist hier abhängig von der eingesetzten Weiterleitungstechnik und dem Browser des Clients.

Gibt es solche Links bzw. wo landest du, wenn du im Browser auf die IP zugreifst?

Oder eine – mir nicht konkret bekanntes – Browsererweiterung, die sowas zur “Anonymisierung” setzt. Nicht unbedingt sinnvoll (man könnte den Referrer ja auch einfach leer lassen), aber hier gibt es einige seltsame Konstruktionen…

Wenn Nein:
Dann wertet Statify den “Referer” HTTP Header aus.

Dann kann es neben der o.g. Möglichkeit sein, dass die Serverkonfiguration nicht optimal ist und die Header unvorteilhaft füllt. Wird PHP als FCGI oder FPM Modul eingesetzt, wird die Anfrage formal intern umgeleitet. Je nach Szenario müssen hier die Header korrekt durchgeschliffen werden. Gleiches Spiel für Reverse Proxy Setups.

Wenn du Zugriff auf Access-Logs des Webservers hast und hier die betreffenden Header rausloggen kannst, wäre das sicher aufschlussreich.

—-

Es kann natürlich auch eine seltsame Form vom Referer Spam sein oder irgendein exotischer Bot, der als Pseudo-Referer die Ziel-IP nutzt, oder ein Monitoring-System das durch den Filter fällt. In Statify 1.7.0 wurde die Filter-Liste für Bots unvollständig umgestellt und in 1.7.1 wieder nachgebessert…

Gruß,
Stefan

• This reply was modified 5 years, 11 months ago by Stefan Kalscheuer.

Hallo Inga,

Bei den Fehlern sehr ich zwei js-fehler (preload und jquery) sowie 2 Fehler, die im Quellcode meiner Seite zu finden sind.
[…]
ich nehme an, dass das aktuelle Statify-Problem auf die beiden js-Script-Fehler zurückzuführen ist. Richtig?

Indirekt wahrscheinlich Ja. Wenn der Browser beim JS einmal in Fehler läuft und das nicht im Skript selbst abgefangen wird, läuft in der Kette danach auch nichts mehr weiter.

Was geladen wird, hängt natürlich von deinem Browsercache, den lokal im System installierten Schriftarten, etc. ab. Mein Testbrowser ist “jungfräulich”, also zu erwarten, dass ich mehr Ladefehler bekommen hatte.

Was bedeutet “CORS Sicherheitseinstellungen” und wo finde ich die?

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Im Prinzip setzt der Webserver oder die Anwendung HTTP-Header, die vorgeben, welche Ressourcen auf welche Weise von wo geladen werden dürfen. Ob das der Webserver macht, ein WordPress Plugin lässt sich von außen nicht sagen.

Das Problem betraf die Schriftarten, da sie von einer anderen (Sub)Domain kamen – scheint ja inzwischen gelöst.

—-

Die jetzt noch relevante Meldung ist

Refused to execute inline script because it violates the following Content Security Policy directive: “script-src ‘self'”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-Oo1bdSPsp6CjaJ69F4foXm6agCkwFfBGUBZTPn9iRfM=’), or a nonce (‘nonce-…’) is required to enable inline execution.

“Verursacht” durch eine “Content Security Policy” default-src 'self'.
(https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)

Erfreulich, solche Einstellungen in freier Wildbahn zu finden, wird oft genug ignoriert.
Allerdings hat CSP auch viele Fallstricke, da Systeme wie WordPress eben doch an diversen Stellen Inline-JS, also Skript-Blöcke im HTML einsetzen, ohne passende Behandlung.

Einfache Abhilfe könnte eine Erweiterung wie script-src 'unsafe-inline' https://ingalandwehr.de schaffen oder auch beliebig komplexere Konfiguration.

Wo die Daten gesetzt werden, kann man von außen natürlich nur vermuten. Ich hoffe die Ansatzpunkte helfen weiter.

Gruß,
Stefan

Hallo Inga,

macht ja nichts.

HTML Code sieht man über REchtsklick -> Quellcode anzeigen (oder meist Strg+U bzw. Option+Cmd+U). In den “Entwickler-Tools” des Browsers (die man natürlich auch als Nicht-Entwickler benutzen darf), erreichbar meist über F12, gibt es i.d.R. einen Reiter “Netzwerk”, der die einzelnen Anfragen auflistet.

Sieht z.B. so aus (andere Browser vergleichbar): https://developers.google.com/web/tools/chrome-devtools/network#load

Deine Seite sieht nach flüchtiger Beurteilung prinzipiell gut aus (auch technisch 😉 ), d.h. das aktuelle Statify ist im Autoptimize Block enthalten und die Variable ist auch vorhanden. Soweit so gut.

Allerdings sehe ich in der Browserkonsole Fehlermeldungen, dass durch Sicherheitseinschränkungen Skriptausführung blockiert wird. Die betroffene Zeile ist ein “shariff”-Block, da hier aber abgebrochen wird, ist auch die “var statify_ajax = …” Zeile betroffen. Entsprechend wird das Skript später zwar aufgerufen, aber kann ohne Konfiguration nicht arbeiten.

Ich würde dir empfehlen, die Einstellungen der Seite einmal zu prüfen oder prüfen zu lassen. Das Problem betrifft tendenziell nicht nur Statify (die Methodik, wie WordPress die AJAX-Blocks initialisiert ist ja für alle gleich). Auch wird durch eine CORS Sicherheitseinstellung verhindert, dass diverse Schriftarten von der Subdomain “tgc.ingalandwehr.de”, was sicherlich auch nicht in deinem Sinn ist.

Gruß,
Stefan

Wenn es schon um Gesamtzahlen geht, warum sollen denn nur Zahlen aus dem im Widget eingestellten Zeitraum angezeigt werden. Ich finde, es könnte das Datum von dem Tag der Erstaufbewahrung verwendet werden.

Genau so habe ich es in meiner Korrektur gemacht. Wenn die Änderung durchkommt, wird dann der gesamte Zeitraum der Datenbank korrekt ausgegeben.

So war die Funktion ursprünglich auch gedacht, dann kam die Trennung Anzeige/Speicherung parallel dazu und am Ende hat keiner mehr so genau hingesehen, ob das wirklich zusammen passt…

Gruß,
Stefan