• Resolved blacckmamba

    (@blacckmamba)


    Hi there,

    I found an 400 error on a website that is caused by statify. I found it here:

    snippet.min.js:1

    ((function(){var statifyReq;try{statifyReq=new XMLHttpRequest();statifyReq.open(‚POST’,statify_ajax.url,!0);statifyReq.setRequestHeader(‘Content-Type’,’application/x-www-form-urlencoded;’);statifyReq.send(‘_ajax_nonce=’+statify_ajax.nonce+’&action=statify_track’+’&statify_referrer=’+encodeURIComponent(document.referrer)+’&statify_target=’+encodeURIComponent(location.pathname+location.search))}catch(e){}}()))

    How can I resolve this?

    Thanks!
    Blacc

Viewing 14 replies - 1 through 14 (of 14 total)
  • Plugin Support Stefan Kalscheuer

    (@stklcode)

    Hi Blacc,

    which versions of Statify and WordPress are you using?

    And can you provide additional details about the failing request or a link to see the behavior? I’m especially interested in the transmitted POST body, i.e. the parameters “_ajax_nonce”, “action”, “statify_referrer” and “statify_target”.

    Cheers,
    Stefan

    Plugin Support Torsten Landsiedel

    (@zodiac1978)

    Hi @blacckmamba !

    Are you maybe blocking access on the admin-ajax.php file in some way?

    Maybe some Security Plugin, Web Application Firewall or Password Protection.

    All the best
    Torsten

    Thread Starter blacckmamba

    (@blacckmamba)

    Hi Torsten und Stefan,

    nee, leider nicht. Ich hab alle Plugins ausgeschaltet, um der Sache auf die Spur zu kommen. Erst dachte ich, es kommt vom Autoptimize, dann hab ich aber festgestellt, dass mir Autoptimize wegen des verkleinerten snippet.min.js angezeigt wird. Ohne Autoptimize war dann klar, es kommt von Statify. Ich hab das bei allen meinen Seiten, schätze mal seit dem letzten größeren Update von Statify. WordPress ist aktuell, Statify auch. Den Fehler hab ich heute zuerst bei einem Check über Pingdom entdeckt und dann nochmal mit dem Developer Tool von Chrome bestätigt.

    Ich möchte hier nicht unbedingt meine Kundenseiten nennen, sonst tauchen die ja in der nächsten Googlesuche auf 😉 Habt Ihr eine Mail-Adresse, an die ich schreiben kann?

    Plugin Support Torsten Landsiedel

    (@zodiac1978)

    Du kannst einen URL-Shortener nutzen und das dann später wieder löschen.

    Beste Grüße
    Torsten

    Thread Starter blacckmamba

    (@blacckmamba)

    Wie cool, wieder was gelernt 😉

    https://bit.ly/2Ae1jqS

    Ich hab Autoptimize wieder ausgeschaltet.

    Vielen Dank für die Hilfe!!

    Plugin Support Stefan Kalscheuer

    (@stklcode)

    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.

    Thread Starter blacckmamba

    (@blacckmamba)

    Moin,

    ja, in der Tat. Bei dieser und allen anderen meiner Seiten ist jetzt alles wieder roger.

    Bei dieser hier ist es noch unverändert: https://bit.ly/3derFb4

    Ein 403-Fehler. War auch bei allen Seiten 403, nur bei der von gestern war es 400

    Thread Starter blacckmamba

    (@blacckmamba)

    Ah so, sorry:

    Request URL: https://xxx/wp-admin/admin-ajax.php
    Request Method: POST
    Status Code: 403
    Remote Address: xxx
    Referrer Policy: no-referrer
    access-control-allow-credentials: true
    access-control-allow-origin: https://xxx.de
    cache-control: no-cache, must-revalidate, max-age=0
    content-type: text/html; charset=UTF-8
    date: Thu, 28 May 2020 15:26:55 GMT
    expires: Wed, 11 Jan 1984 05:00:00 GMT
    pragma: no-cache
    referrer-policy: no-referrer
    server: Apache/2.4.41 (Unix)
    status: 403
    vary: User-Agent
    x-content-type-options: nosniff
    x-frame-options: SAMEORIGIN
    x-powered-by: PHP/7.3.18
    x-robots-tag: noindex
    :authority: xxx.de
    :method: POST
    :path: /wp-admin/admin-ajax.php
    :scheme: https
    accept: */*
    accept-encoding: gzip, deflate, br
    accept-language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
    cache-control: no-cache
    content-length: 80
    content-type: application/x-www-form-urlencoded;
    cookie: wp-settings-1=libraryContent%3Dbrowse%26editor%3Dtinymce%26edit_element_vcUIPanelWidth%3D650%26edit_element_vcUIPanelLeft%3D994px%26edit_element_vcUIPanelTop%3D196px%26hidetb%3D1%26editor_plain_text_paste_warning%3D1; wp-settings-time-1=1590408332; PHPSESSID=sf7treqp12409mos8k7rnp2rnj
    origin: https://www.xxx.de
    pragma: no-cache
    sec-fetch-dest: empty
    sec-fetch-mode: cors
    sec-fetch-site: same-origin
    user-agent: xxx
    _ajax_nonce: d2e48f2c3e
    action: statify_track
    statify_referrer:
    statify_target: /

    jazzminus

    (@jazzminus)

    Ich habe das gleiche Problem auf meiner Seite. Soeben habe ich festgestellt, dass der Fehler in der Console verschwindet, wenn ich die Checkbox bei

    “Tracking ausschließen für …” -> Angemeldete Benutzer

    deaktiviere.

    Plugin Support Stefan Kalscheuer

    (@stklcode)

    403 am AJAX Endpunkt bedeutet für gewöhnlich Nonce, also Einmalcode zur Identifizierung abgelaufen. Diese sind standardmäßig 24h gültig.

    Zumindest auf der Seite von @blacckmamba war Cache Enabler aktiv. Hier ist nicht zufällig eine längere Zeit konfiguriert?

    @jazzminus Welche Fehlercodes erhälst du, auch 403 oder etwas anderes?
    Die Option für angemeldete Benutzer dürfte auf das Verhalten keinen Einfluss haben, aktiviert lediglich eine zweite AJAX Action mit dem selben Namen (rein technische Gründe, angemeldet und anonym sind im Backend getrennt) und nimmt einen Filter raus. Da Caching für angemeldete Nutzer aber meist deaktiviert ist, wäre das eine mögliche Erklärung.

    Hättest du ansonsten ggf. eine öffentliche URL sodass wir das Problem nachvollziehen können? Wenn es zufällig die aus deinem Profil ist, dann erhalte ich Stand jetzt einen korrekten 204.

    Ich hatte einen 400er-Fehler in der Console mit Verweis auf admin-ajax.php. Meine Autoptimize-Einstellung für eingeloggte Benutzer ist aktiviert, d. h. auch für angemeldete Benutzer wird optimiert. Wenn ich diesen Haken rausnehme, also nicht mehr für eingeloggte Benutzer optimiert wird, habe ich ebenfalls keinen Fehler mehr. Scheinbar macht das also nichts aus.
    Die URL ist Packlisten.org.

    Plugin Support Stefan Kalscheuer

    (@stklcode)

    Ich habe den Fehler 400 mittlerweile reproduzierbar nachstellen können.

    Er tritt auf, wenn Tracking für angemeldete Benutzer deaktiviert ist (wie von @jazzminus beschrieben), dann aber nur bei angemeldeten Benutzern.
    Grund ist, dass die AJAX Aktion in diesem Fall gar nicht registriert wird und der Endpunkt diese abweist.

    Das Fehlerbild ist harmlos, da es nur auftritt, wenn sowieso nicht getrackt werden soll. Da es aber das Log mit unnötigen Meldungen zumüllt, werden wir das Problem mit einem kommenden Update korrigieren. (https://github.com/pluginkollektiv/statify/pull/159)

    —-

    Der Fehler 403 hat eine andere Ursache, höchstwahrscheinlich eine zu lange bzw. nicht zum Nonce-Timeout passende Caching-Zeit. Etweder die Caching-Zeiten auf sicher <24h reduzieren oder die Nonce Lifetime entsprechend erhöhen (https://codex.ww.wp.xz.cn/WordPress_Nonces section “Modifying the nonce lifetime”)

    Thread Starter blacckmamba

    (@blacckmamba)

    Fantastisch, danke für die schnelle Unterstützung!

    Danke für euren Support! 👍

Viewing 14 replies - 1 through 14 (of 14 total)

The topic ‘Statify causes 400 error (admin-ajax.php)’ is closed to new replies.