Statify causes 400 error (admin-ajax.php)
-
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
-
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,
StefanHi @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
TorstenHi 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?
Du kannst einen URL-Shortener nutzen und das dann später wieder löschen.
Beste Grüße
TorstenWie cool, wieder was gelernt 😉
Ich hab Autoptimize wieder ausgeschaltet.
Vielen Dank für die Hilfe!!
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.
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
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: /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.
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.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”)
-
This reply was modified 5 years, 11 months ago by
Stefan Kalscheuer.
Fantastisch, danke für die schnelle Unterstützung!
Danke für euren Support! 👍
-
This reply was modified 5 years, 11 months ago by
The topic ‘Statify causes 400 error (admin-ajax.php)’ is closed to new replies.