Stefan Kalscheuer

Forum Replies Created

Viewing 15 replies - 46 through 60 (of 157 total)
1 2 3 4 5 … 9 10 11
  • Forum: Plugins
    In reply to: [Statify] Statify shows nothing
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    4 years, 4 months ago

    Hi,

    was anything else changed within the collection period (the last weeks or since whenever it worked)? Caching, theme, other plugins… Typically something does not simply stop working for no reason.

    Assuming the output is correct, the obvious reason for “no data” is that there is no date, i.e. no visit was tracked within the configured period.

    Reasons for this can vary. For Non-JS tracking every way of caching breaks data collection – however it’s quite tricky to get really no data at all, except for some cache-warming logic that does not trigger tracking by itself.

    For JS tracking a theme that does not call wp_footer() and thus does not include the Statify script in the output DOM breaks tracking. Also some arbitrary JavaScript error in any other plugin/snipped might cause the browser to stop processing further scripts. I’ve also seen some “admin lockdown” attempts that block calls to /wp-admin/admin-ajax.php.

    Both mechanisms are affected by exclusion filters, incorrect/missing user agent headers or similar.

    Without any additional information about the plugin configuration or the site itself, we can only guess what’s happening here.

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [Cachify] Cachify plugin breaks Facebook sharing
    Stefan Kalscheuer

    (@stklcode)

    4 years, 5 months ago

    Thanks for your analysis. I totally forgot about the pre-compressed stuff, seems obvious though.

    Just checked GZ files generated by Cachify, they seem to be valid, so the PHP GZip module is not broken – at least in my test container.

    My suspicion is that the response is missing the expected headers, so the compressed content is transmitted, but a strict client fails to read it without proper indication. (browsers do forgive quite a lot, so very likely no human visitor ever noticed an error)

    I don’t have an Apache+WP site on hand to verify. If I’m right, an additional directive like this should fix the problem (documentation should be updated in this case):

    <FilesMatch "\.html\.gz$">
    Header append Content-Encoding gzip
    Header append Vary Accept-Encoding
</FilesMatch>

    Your site does provide the correct headers now that the server handles compression on-the-fly. (didn’t test that case yesterday)

    Forum: Plugins
    In reply to: [Cachify] Cachify plugin breaks Facebook sharing
    Stefan Kalscheuer

    (@stklcode)

    4 years, 5 months ago

    Hi @markhowellsmead,

    the old post is now 7 months old without any answer, but I’d assume the reported issue is the very same: Facebook always gets HTTP 206

    First pleas note that I do not have any clue what the FB debugger does. Nevertheless let’s try tracking down the issue.

    According to the HTML signature you’re using HDD caching.
    Furthermore from reading the sources and plugin files, you’re using WP 5.8.2 with Cachify 2.3.2.

    Next, let’s have a look into the response headers for cached and uncached requests (headers with different contents only):

    Cached:

    Content-Type: text/html
Last-Modified: Sat, 20 Nov 2021 18:16:13 GMT
Etag: "199a8-61993b6d-97ee3b82b6c57da1;;;"
Accept-Ranges: bytes
Content-Length: 104872

    Uncached:

    Content-Type: text/html; charset=UTF-8
X-Pingback: https://permanenttourist.ch/xmlrpc.php
Link: <https://permanenttourist.ch/wp-json/>; rel="https://api.w.org/"
Link: <https://permanenttourist.ch/wp-json/wp/v2/posts/62742>; rel="alternate"; type="application/json"
Link: <https://permanenttourist.ch/?p=62742>; rel=shortlink

    When static content (i.e. cached HTML file) is served, the webserver accepts partial content, indicated by the Accept-Ranges header (MDN), so 206 codes are probably fine when partial content is actually requested.

    E.g. requests like

    $ curl -i -H 'Range: bytes=0-1024' https://permanenttourist.ch/2021/11/axalp-in-the-snow/
$ curl -i -H 'Range: bytes=1024-2048' https://permanenttourist.ch/2021/11/axalp-in-the-snow/

    do exactly what they are expected to do, deliver first and second 1kB-slice with status 206 and header Content-Range: bytes 0-1024/104872.

    Second the Content-Type header (MDH) is missing a charset value, that’s what might lead to a bad encoding error.

    Are you in control of any webserver settings?
    Do you have access to server logs that indicate the request headers the FB debugger uses?

    Try opening a cached HTML file from the wp-content/cache/cachify/ directory and verify the encoding in a text editor of choice.

    Second thing I would try is placing an arbitrary HTML file anywhere on the server and see what the FB debugger does with that.

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [NSFW] [Statify] Merkwürdige Quellenangabe
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    4 years, 7 months ago

    Hi Björn,

    sieht auf den ersten Blick wie eine versuchte Header Injection aus. Es sind SQL Fragmente zu erkennen, die, wenn sie bspw. ganz naiv in ein Statement zur Statistikerfassung eingebunden werden, Daten abgreifen, verändern o.Ä.

    Auf Statify trifft das nicht zu, hier wird bei den DB Operationen sauber escaped (offensichtlich, das Zeug ist ja da angekommen, wo es hin gehört). Also ist es hier glücklicher Weise nur Datenmüll.

    Vielleicht sollte man die Plausibilitätsprüfung für Referrer URLs mal etwas nachschärfen.

    Wobei das ganze mit dbms_pipe oder pg_sleep generell eher nicht so aussieht, als sei WordPress das Ziel, da diese Funktionen in den unterstützten MySQL/MariaDB Datenbanken so im Regelfall nicht existieren.

    Sieht man immer wieder mal in verschiedensten Formen, gerne nachdem (oder kurz bevor) Sicherheitslücken in Serversoftware oder Frameworks bekannt werden. Dann füttert man sein Botnetz damit und lässt es auf das Internet los. Irgendein Zufallsopfer findet man immer. Je nach Popularität und Impact gern mal koordiniert hunderte Anfragen pro Minute (Confluence vor ein paar Wochen war großartig, eine Woche lang rund 5-10/s auf zwei eher kleinen Instanzen, erst Fernost, dann Osteuropa und etwas GCP/AWS, … aber da war das Potenzial auch nicht ohne, wenn’s klappt). Meist eher harmlos, kurz mal ein paar hundert über wenige Tage. (wenn nicht, sollte man etwas weiter analysieren, warum man so Fokus steht)

    Wenn du Serverlogs im Zugriff hast, zeichnet sich ggf. ein simples Muster ab, sodass man ggf. wenige Subnetze sperren kann.

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Statify Filter] DDNS nötig um eigene IP zu filtern?
    Plugin Author Stefan Kalscheuer

    (@stklcode)

    4 years, 7 months ago

    Hallo @lenaka,

    ich fürchte, ein DynDNS Dienst wird dir beim deinem Vorhaben nicht weiterhelfen. Damit kannst du zwar von außen immer gleich auf dein Netz zugreifen, umgekehrt ist die Zuordnung aber nicht zwangsläufig möglich.

    Ein anderer Ansatz: Bist du i.d.R. auf der Seite eingeloggt? Wenn Ja, ist das Ausschließen angemeldeter Nutzer (Statify Standardeinstellung) eine Option?

    Dritte Variante:
    Man könnte man mit wenigen Zeilen Code einen eigenen Filter schreiben, der z.B. auf ein individuelles Cookie o.Ä. prüft, das du in deinem Browser einmal hinterlegst.

    Gruß,
    Stefan

    —-

    Ein wenig Hintergrund dazu: (nicht notwendig)

    Was der Server sieht, ist einmal die IP Adresse des Clients und, sofern vorhanden, ein Reverse-DNS Eintrag zu dieser Adresse (angenommen die IP sei 198.51.100.42, dann i.d.R. etwas wie “198-51-100-42.pool.provider.example.com” – diese Einträge werden vom Eigentümer der IP gesetzt, bei Privatkunden also fast ausschließlich vom Provider vorgegeben). Welche Hostnamen auf die IP Adresse zeigen, ist nicht ohne weiteres herauszufinden, d.h. der Webserver weiß leider nicht ohne zusätzliche Abfragen, dass “lenaka.dyn.example.com” heute auf 198.51.100.42 zeigt.

    Entweder man findet also einen anderen Weg, der WP Konfiguration mitzuteilen, welche IPs auszuschließen sind (eigenes Pseudo-DDNS-Plugin, sodass die IP nicht an einen DNS-Dienst, sondern an dein WP gesendet wird) oder man findet einen ganz anderen Weg. Ich schätze wenn ersteres kein Problem wäre, würden wir hier nicht darüber sprechen 😉

    Forum: Plugins
    In reply to: [Statify] POST admin-ajax
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    4 years, 10 months ago

    First of all please note, that the POST request is an asynchronous “fire and forget“ request and does not impact site rendering time or block the loading chain.

    AJAX requests are not cached design. The actual processing time strongly depends on factors like the number of plugins that do initialize (some ignore AJAX and opt out early, some do full initialization) and finally of course the server performance.

    Without detailed analysis and comparison on the actual platform, there is no general answer if improvements are possible or how.

    It takes longer than anything else.

    Longer than cached, static files, is normal and expected. On my sites I do see a difference of 3-8ms for static files (including cached page markup) and 150-200ms for AJAX POST. That is of course significantly more, but the absolute time is far from bad and I would not spend a minute of analysis in this case.
    I’ve seen times of 1s and more for a full, uncached WP cycle in the wild. That’s slow, but not quite unusual.

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [Cachify] Cachify with Elasticache
    Stefan Kalscheuer

    (@stklcode)

    4 years, 10 months ago

    Hi,

    Whenever I configure it with the cluster endpoint URL / PORT it seems like its not sending items to the Memcached cluster.

    Just to be sure, you’re doing something like this, right?

    apply_filter( 'cachify_memcached_servers', fn () => [ [ '*****.cache.amazonaws.com', 11211 ] ] );
    (or equivalent older PHP notation)

    Note the nested array, because the result is passed to addServers().

    I have confirmed that I am able to access elasticache from the EC2 via telnet

    Have you checked via PHP? E.g. with such simple roundtrip script using the same settings and methods Cachify uses (just hacked down, might contain typos)

    <?php
echo "initialize memcached";
$memcached = new Memcached();
if ( ! $memcached ) die(" FAILED");

echo " ✓\nconfigure memcached";
$res =$memcached->setOptions( array( Memcached::OPT_COMPRESSION  => false, Memcached::OPT_BUFFER_WRITES => true, Memcached::OPT_BINARY_PROTOCOL => true ) );
if ( ! $res ) die(" FAILED");

echo " ✓\nadd servers";
$res =$memcached->addServers( array( array( '*****.cache.amazonaws.com', 11211) ) );
if ( ! $res ) die(" FAILED");

echo " ✓\nwrite test object";
$res = $memcached->set( 'testkey', 'testvalue', 60 );
if ( ! $res ) die(" FAILED");

echo " ✓\nread test object";
$res = $memcached->get( 'testkey' );

if ( 'testvalue' !== $res ) {
    echo " FAILED\n";
    print_r( $res );
    exit(1);
}

echo " ✓\ndelete test object";
$res = $memcached->delete( 'testkey' );
if ( ! $res ) die(" FAILED");
echo " ✓";

    If this didn’t do the job yet… Are you using the distribution’s or PECL extension for Memcached or the ElastiCache extension?
    Cachify always calls addServers() with [['127.0.0.1', 11211]] by default which might interfere with the autodiscovery feature. I haven’t tried yet, but you could try an empty argument in this case:
    apply_filter( 'cachify_memcached_servers', fn () => [] );

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [Statify] Statify & Caching?
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    4 years, 10 months ago

    Hallo Axel,

    das Problem ist immerhin einfach: Caching-Zeit länger als Nonce-Gültigkeit (s.o.)
    Die AJAX Anfrage von Statify liefert auf gecachten Seiten aktuell fast ausschließlich “403 Forbidden”, ohne Cache ordnungsgemäß 204.

    Passt soweit ganz gut zur Beobachtung, direkt nach dem Neuaufbau des Caches sind die Daten frisch, alles gut. Dann laufen die Nonces zunehmend ab nach 8-12h werden zunehmend weniger Seiten erfasst. Bis der Cache neu aufgebaut wird, durch Ablauf oder Bearbeitung einzelner Inhalte, dann geht das Spiel von vorne los.

    Bei entsprechend langen Cache-Zeiten würde es sich wohl anbieten, die Nonce-Prüfung für die Statistik zu deaktivieren (in den Statify Einstellungen). Sollte dieses Problem unmittelbar lösen.

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Statify] Statify & Caching?
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    4 years, 10 months ago

    Hallo Axel,

    jetzt sieht es etwas anders aus.
    Ohne Cache wird korrekter Weise /wp-content/plugins/statify/js/snippet.min.js eingebunden und ruft sauber wp-ajax.php auf. Kommt mit Status 204 zurück, so sollte es sein.

    Mit Cache fehlt das JS Snippet, dafür gibt es dann eine /cache/wpfc-minified/…/…js, in der eigentlich alle JS Ressourcen zusammengefasst werden sollten.

    Die ist recht überschaubar, es fehlt aber auf jeden Fall Statify.
    Andere Ressourcen werden z.T. ganz normal eingebunden.

    Ich sehe entsprechend auf der gecachten und “optimierten” Seite 2 Fehler:

    • Statify tut nichts
    • UberMenu muss auf Fallback zurückgreifen und liefert die Meldung in der Browserkonsole:

      Notice: UberMenu initialized via window.load. This indicates that an unrelated error on the site prevented it from loading via the normal document ready event.

    Da aber ohnehin nur ein sehr kleiner Anteil der Skripte zusammengefasst wird, bringt dies Einstellung im gegebenen Szenario auch nicht allzu viel. Ich würde zunächst versuchen, diese Funktion abzuschalten: “JS kombinieren”.

    Wenn das nicht hilft, wäre meine nächste Vermutung, dass es ein Problem beim Preload (“Vorlagen”) geben könnte, sodass Statify der Meinung ist, kein Skript einbinden zu müssen und die Seite entsprechend ohne gecacht wird.

    Ich komme heute auf jeden Fall nicht mehr dazu, ein Testszenario aufzubauen und einmal zu debuggen, welche Kombination das Problem verursacht, werde es mir die Tage aber auf jeden Fall noch einmal ansehen. Ich weiß, dass WP Super Cache und JS Zusammenfassung mit Autoptimize keine Probleme machen, also kein generelles NoGo. Aber hier läuft es ganz offensichtlich nicht rund.

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Statify] Statify & Caching?
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    4 years, 10 months ago

    Wenn die verlinkte Seite eine der betroffenen ist, fehlt hier jede Spur von Statify, auch wenn ich Laden am Cache vorbei durch willkürliche Parameter in der URL (z.B. …?nocache – fast 10fache Ladezeit wird wohl ohne Cache sein) erzwinge. Das Problem liegt also nicht unmittelbar am Caching.

    Du verwendest hier offenbar die WPFC JavaScript „Optimierung“, d.h. JS Ressourcen werden nicht direkt eingebunden, sondern zusammengefasst. Hier fehlt der Statify Teil auf jeden Fall – schlecht.

    Ich habe die Einstellungen nicht vor Augen, ggf. kann man das Statify JS davon ausschließen. Das Plugin fügt die Ressource erst recht spät in der wp_footer() Phase hinzu, wenn vorher schon rausgesprungen wird, wäre das problematisch.

    Die Seite wirft JavaScript Fehler durch einen eingebetteten Avia Cookie Consent Schnipsel, der ausgeführt wird, bevor JQuery geladen ist. Das sollte auf jeden Fall auch korrigiert werden, ob es mit dem Problem zusammenhängt schwer zu sagen.
    UnerMenu beklagt sich auch, dass die normale Initialisierung (sehr wahrscheinlich dadurch) nicht funktioniert und ein Fallback greifen musste.

    Zu den Nonces.
    Ganz kurz: WP generiert für AJAX Anfragen Einmalcodes (Nonces), um zu legitimieren, dass die Anfrage wirklich von der Seite kommt. Sind nicht ewig gültig, daher kann es bei langen Caching-Zeiten vorkommen, dass die Anfragen mit Status 401 abgewiesen werden. Kann man abschalten, geht ja „nur“ um Statistik, also im Regelfall nichts kritisches. Sollte man im Hinterkopf haben, ist hier aber nicht das Problem.

    https://codex.wordpress.org/WordPress_Nonces

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Statify] Statify & Caching?
    Plugin Support Stefan Kalscheuer

    (@stklcode)

    4 years, 10 months ago

    Hallo Axel,

    hast du JavaScript basierte Erfassung in den Statify Einstellungen aktiviert? Bei längeren Caching anzeigten ggf. mit abgeschalteter Nonce-Prüfung, falls die Gültigkeit nicht ebenfalls erhöht ist.
    Ohne wird bei Antworten aus dem Cache nichts erfasst und die Zahlen liegen entsprechend deutlich zu niedrig.

    Ich betreibe selbst ein paar Seiten mit Statify und WP Super Cache und Caching-Zeiten 4-12h ohne Schwierigkeiten.

    Gruß,
    Stefan

    Forum: Plugins
    In reply to: [Cachify] cache folder
    Stefan Kalscheuer

    (@stklcode)

    4 years, 11 months ago

    Hi @peterkuwi,

    Cachify stores its data in a subdirectory wp-content/cache/cachify.

    The cache directory must be readable and writable by the user running the PHP process and readble by the user running the webserver (if different). This should be the case already, otherwise several WP functions would complain.

    Cachify creates the necessary structure during the installation. There should be no need to grant extended permissions manually (777 is most likely unnecessarily high, if the server is well configured, 77x or 75x is typically fine).

    Cheers,
    Stefan

    Forum: Plugins
    In reply to: [AntiVirus] Should not alert in PHP comments
    Plugin Author Stefan Kalscheuer

    (@stklcode)

    4 years, 11 months ago

    You are right, comments usually won’t do any harm.

    The theme file scan in the current version is pretty simple, as it scans each line of PHP sources and applies a set of expressions to them, mainly to identify potentially malicious code patterns. Many of them ca be used for good, too, so false positives in the first run are likely normal for complex themes.

    A really dumb implementation that scans for /* or // won’t do the job here, as it’s easy to work around and target for false positives itself, so the routine has to be extended quite a bit.

    We will note this (reasonable) request, but to be honest I would not expect to see this extension in the near future. However, everybody is invited to contribute.

    Regards,
    Stefan

    Forum: Plugins
    In reply to: [Cachify] Cachify-Clearing-Cache deleting Reflinks?
    Stefan Kalscheuer

    (@stklcode)

    4 years, 11 months ago

    The “clear cache” button does exactly one thing: clear the cache. So afterwards all cached HTML content is gone and the pages will be re-built by WordPress on the next visit.

    My intuition is: No, it does not break anything.
    But anyway it can be tested easily, right? Just simulate a regular user and flush the cache from another browser….

    Little more detail:
    There are only 2 scenarios I can imagine where clearing the cache removes something from the markup:

    1. the link is only present in the cached markup
    2. the cached link is no longer available

    For the former there is no realistic way to achieve this, because one would have to actively modify the cache data (this is likely not done accidentally).

    For the latter case one could consider the cache to be outdated anyway. Relying on outdated cache in general is a really bad idea, because it can be cleared at any time by various actions.

    Edit: apparently Torsten was faster. Left the reply window open for quite some time…

    Forum: Plugins
    In reply to: [Statify Filter] Admin Besuche und eigene IP wird geloggt
    Plugin Author Stefan Kalscheuer

    (@stklcode)

    5 years, 3 months ago

    Ich habe gerade einmal quergetestet.

    • leere WP 5.6 Installation
    • PHP 8.0 FPM mit nginx Webserver
    • Theme OnePress 2.2.6
    • Statify 1.8.1
      JavaScript Tracking aktiviert, sonst default

    Soweit alles gut, eingeloggte Besucher werden nicht gezählt, anonyme Nutzer schon.

    Installation von W3 Total Cache 2.1.0 und dann die folgenden Schritte abgearbeitet (nach jedem Punkt Statify getestet):

    • W3TC aktivieren, ohne Setup
    • Page Cache (Disk Enhanced) aktivieren
    • Minification aktivieren
      alle HTML Optionen (inline CSS/JS, line break) mit “Minify”
      CSS (Combine & Minify) mit “Minify”
      JS (Combine & Minify) mit “JSMin”
    • Database Cache aktivieren (Disk)
    • “Don’t cache queries for logged in users” deaktivieren
    • Object Cache (Disk) aktivieren
    • Browser Cache aktivieren (Default Einstellungen)

    Konnte (leider oder zum Glück, wie man’s nimmt) keine Fehlfunktion feststellen.

    Mir fehlt an diesem Punkt leider etwas der Angriffspunkt für weitere Tests. Wenn du magst, kannst du mir die Inhalte der Optionen w3tc_* und statify zukommen lassen (falls irgendwas geheimes drinsteht raus damit oder privat per Mail/Slack)

    Gruß,
    Stefan

Viewing 15 replies - 46 through 60 (of 157 total)
1 2 3 4 5 … 9 10 11