Stefan Kalscheuer

Hallo Dieter,

darüber, wie diese URLs in den Suchindex geraten sind, lässt sich leider nur mutmaßen.

Bis Statify 1.6 wurden solche URLs tatsächlich zum Tracking genutzt, allerdings sollten diese auf die Home-URL der Seite zeigen, nicht auf eine Unterseite (also i.d.R. /?statify_referrer=...&statify_target=...) und liefern dann auch keine gültige Seite, sondern eine leere Antwort.
Bis 1.5 wurde dazu ein Pseudo-Element <script> eingebunden, danach erfolgte der Aufruf direkt aus dem JavaScript heraus. Aber eigentlich nie direkt durch einen Link oder Benutzeraufruf.

Seit 1.7 werden solche Aufrufe nicht mehr verarbeitet, entsprechend läuft der ganz normale WordPress Zyklus durch (Ergebnis s.u.)

Vermutlich kamen hier diverse Punkte zusammen. Eine mögliche Erklärung wäre, dass eine Seite, die vor dem Statify 1.7 Update bereits im Cache lag, solche (nicht mehr funktionierenden) Tracking-Aufrufe abgesetzt hat, die dann eine normale HTML Seite liefern. Eines der eingebunden Google Skripte könnte diesen Aufruf als gültig interpretiert haben (ist er ja auch) und entsprechend hat der Suchindex diese URL gelernt.
Ggf. kam noch ein Theme-Wechsel oder eine Umkonfiguration dazu, was die Seite 4 erklären würde. Den Punkt finde ich aber hier eher zweitrangig.

Ich finde das sehr merkwürdig, da die URLs aufrufbar sind und eine Blogübersicht zeigen.

Dieser Teil ist tatsächlich das einzig nicht merkwürdige.
/page/<Nummer> ist ein Standardmechanismus von WordPress, der auf die entsprechende Seite der Blog-Übersicht verweist. Bei vielen Themes, die die Standardmethodik zum Blättern nicht nutzen – so wie deines – wird der zusätzliche Parameter einfach ignoriert. Du kannst auch /page/99999 aufrufen. Statify hat hiermit nichts zu tun, der Parameter am Ende tut nichts.

Nach flüchtiger Übersicht deiner Seite sieht das ganze eigentlich soweit gut aus und es sind keine Hinweise auf eine derartige URL oder ähnliche Überreste alter Statify-Verhalten auffindbar.

Gruß,
Stefan

Hi,

currently this is possible using a filter hook statify__user_can_see_stats (https://statify.pluginkollektiv.org/documentation/hooks/#user_can_see_stats)

You case would be something like the example from the docs:

add_filter(
    'statify__user_can_see_stats',
    current_user_can('edit_others_pages' )
);

A more convenient configuration is planned for next point release 1.8, however no ETA yet. (https://github.com/pluginkollektiv/statify/issues/106)

Cheers,
Stefan

Joah… Ich zitiere aus dem WP Core Code: “This is the best attempt to reverse that operation into a local time to use.”

Der übergebene Zeitpunkt wird als UTC gesehen und der Offset (erneut) herausgerechnet. Meine Vermutung hier wäre, dass es von der System und/oder PHP-Zeitzone abhängt, was die Rechnung hier tut. Auf meinem lokalen Testsystem (alle Zeitzonen einheitlich Europe/Berlin) passt es. Im Container (System+PHP auf UTC, WP Berlin) verschiebt es sich nach vorne, was unkritisch ist. Aber eben so kann ein negativer Offset reinkommen, dann sind wir bei Uhrzeit 00:00:00 (wir speichern ja nur das Datum) eben einen Tag zurück.

Wir speichern hier bereits “lokale” Zeitstempel, d.h. die Zone interessiert uns bei der Ausgabe gar nicht mehr. Wir sollten also entweder alles als “UTC” ansehen oder Konversion gänzlich ignorieren (z.B. gemäß Thorstens Vorschlag).

Gruß,
Stefan

Alles klar, das macht mehr Sinn 😉

Das wundert mich allerdings, da ich gestern Abend die Cachedauer auf 12 Stunden gestellt habe. Cron wird extern getriggert.

Das wären eigentlich recht ideale Bedingungen. Allerdings kenne ich das Caching Plugin nur flüchtig, daher kann ich hier mögliche Ursachen auch nur raten.

Ich verwende selbst oft ~12h, was bei hoher Nutzerzahl und/oder externem Trigger eigentlich +/- 15min hinkommt…

Geht die Erhöhung der Nonce-Lifetime nicht mit einem höheren Sicherheitsrisiko einher?

Ja und Nein. Es kommt letztlich etwas darauf an, wofür sie konkret genutzt werden.
Es sind (offensichtlich) keine wirklichen Einmaltoken. Plugins, die Nonces als solche verwenden, sollten diese auch unmittelbar nach Verwendung aktiv invalidieren oder eine eigene Methodik mitbringen. Im Falle von Statify eher unkritisch.
(man könnte sich fast überlegen, die Prüfung deaktivierbar zu machen… bis 1.6 gab es die gar nicht – sollten wir im Team mal diskutieren)

Den Cache wollte ich ursprünglich so lange wie sich nichts ändert, erhalten, da die Website dann einfach schneller ist.

In solchen Fällen liefert eine (zuverlässige) 12h Dauer und ein Preload-Trigger (externes Cron verwendest du ja bereits) aus Anwendersicht gleichermaßen schnelle Ergebnisse.

WP Rocket empfiehlt bspw. 10h oder weniger, um gänzlich sicher zu gehen, also min. Nonce-Lifetime minus Cron-Puffer.

Letztlich muss irgendwo ein Kompromiss aus Client-Performance, Server-Last und Sicherheit her. Ob das 8h Preload oder 48h Nonce-Lifetime ist, ist pauschal kaum zu beantworten.

I just had a short look at your site again.

The WP AJAX call give an error code 403 (i.e. my visit to the front page was not counted) and last lines of the HTML markup show a caching time 58 hours ago.

Cache file created on: 2020-06-27T07:52:14+00:00
Current time: 2020-06-29T17:59:22+00:00

Reason for the 403 is most likely the ~24h (or at least below 58h) nonce lifetime here.

Ich hatte in einem anderen Thread einmal die Nonce-Problematik angeschnitten: https://wordpress.org/support/topic/crazy-counting/#post-12946894

Weniger als 24h ist im Regelfall unkritisch (nicht exakt, im Zweifelsfall lieber etwas weniger wählen). Je nach Szenario können sich aber mehrere Caches (WP Plugin, Webserver, Proxy, Browser) und so effektiv länger das selbe HTML liefern.

Geht man höher, kann man die Gültigkeit der Nonces auch mit erhöhen (https://codex.wordpress.org/WordPress_Nonces).

Keine pauschale Empfehlung, dafür gibt es zu viele Faktoren, aber kürzere Zeitspanne mit automatischen Preloading kann eine Alternative sein.

Zur Cache Dauer: habe Cache Enabler so eingestellt, dass der Cache nie verfällt, außer bei neuen Kommentaren, neuen Artikeln oder Pluginupdates.

Siehe meine vorherige Ausführung, das kann die sinkenden Zugrriffszahlen erklären. Mit der Zeit sind alle relevanten Seiten >24h im Cache und wenn es dann ein paar Tage keine Änderungen und Plugin-Updates gibt… Falls Deaktivieren eines Plugins die Invalidierung triggert oder im selben Zuge evtl. ein anderes Updates gemacht wurde, kann das Verhalten ebenfalls passen.

PS: Ich habe es schon mehrfach in anderen Threads erwähnt: Wenn es ein Caching-Problem ist, sollten sich verstärkt Aufrufe mit Status-Code 403 auf admin-ajax.php im Server-Log finden, sofern einsehbar.