En fejl, der kommer og går, er den værste at diagnosticere, fordi den fejler det mest grundlæggende trin i fejlfinding: at kunne genskabe den på kommando. En “fjern vare”-knap i en butiks kurvskuffe fejlede med en 403 Forbidden -fejl for nogle besøgende, noget af tiden, og der var intet brugbart i PHP-fejlloggen, der pegede på en årsag.
Aflæsning af fejlens signatur
AJAX-forespørgslens svar var et nøgent -1sammen med HTTP-status 403. Netop den kombination er WordPress’ egen signatur for et fejlet kald af check_ajax_referer() , den sikkerhedskontrol af nonce, som enhver korrekt bygget AJAX-handler udfører, før den gør noget andet. Den nonce, siden sendte, passede simpelthen ikke med det, serveren forventede.
Hvorfor en reelt gyldig nonce kunne fejle
WordPress-nonces er ikke permanente; de genereres ved hver sideindlæsning og udløber efter cirka 24 til 48 timer, knyttet til et rullende tidsvindue i stedet for en fast værdi. Sidens fulde sidecache i LiteSpeed var dog sat op med en TTL på 7 dage, så en cachet side kunne serveres uændret til alle besøgende i op til en hel uge, efter den først blev genereret.
Enhver side, der stadig blev serveret fra cachen mere end cirka to døgn efter, den blev cachet, delte en nonce ud, som allerede var udløbet, når en rigtig besøgende prøvede at bruge den. Ikke på grund af noget galt med netop den besøgendes session, men fordi selve HTML’en var forældet i forhold til WordPress’ eget sikkerhedsur.
Rettelsen, og hvorfor det er en rigtig rettelse og ikke en nødløsning
At sænke sidecachens TTL til 6 timer, et godt stykke under WordPress’ minimale levetid for nonces, løste det med det samme og fuldstændigt, fordi det fjerner selve uoverensstemmelsen i stedet for at dulme et symptom. Under undersøgelsen fjernede vi også en separat, uvedkommende dubleret kurvvisning fra checkout-siden, da checkoutens egen ordreoversigt allerede viste de samme oplysninger.
Det vigtigste
- Et svar med
-1og HTTP 403 er næsten et fingeraftryk for et fejlet nonce-tjek i WordPress; værd at kunne genkende med det samme. - TTL for fuld sidecache og WordPress’ egen levetid for sikkerhedstokens er to indstillinger, der skal passe sammen, og intet håndhæver det som standard.
- En fejl, der kommer og går og virker tilfældig, er ofte en timing-uoverensstemmelse mellem to systemer, som hver for sig virker korrekt.
Læs også: en tidsforskydning på seks timer, hvad vedligeholdelse af en hjemmeside reelt dækker.
Støder du på en lignende begrænsning i din egen WooCommerce- eller WordPress-admin? Lad os tale — ArtinTech Solution bygger netop den slags skræddersyede værktøjer til webshops.