Mardrömmen wp-cron.php

BY admin
|

Ett av de stora problem jag har med WordPress är standardimplementationen av wp-cron.php. Om du är bekant med hur WordPress använder wp-cron.php som standard kan du hoppa vidare till nästa avsnitt i den här artikeln.

Filen wp-cron.php är den del av WordPress som hanterar schemalagda händelser inom en WordPress-webbplats. Allt som har att göra med schemaläggning av inlägg eller publikationer och egentligen allt som har med datum/tid att göra styrs av filen wp-cron.php.

För att wp-cron.php ska fungera korrekt måste den exekveras ofta, men inte mer än en gång per minut. Standardbeteendet kräver dock inte att du konfigurerar ett riktigt cron-jobb på systemnivå på din server. Istället används en piggyback-metod för varje inkommande begäran. När en begäran kommer in till webbplatsen genererar WordPress en ytterligare begäran från sig själv till filen wp-cron.php via HTTP(S). Det låter ganska ofarligt, eller hur?

Varför är standardbeteendet wp-cron.php en mardröm?

Standardmetoden fungerar alldeles utmärkt på en liten webbplats med väldigt få besökare per timme. Men när den implementeras på en medelstor eller större webbplats eller till och med en webbplats som skannas av botar (vilket är mycket vanligt nuförtiden) innebär detta att du får dubbelt så mycket trafik som du för närvarande hanterar. Det blir en rudimentär DDoS-attack mot dig själv. Detta beror på att cron körs flera gånger i minuten med hjälp av en HTTP-förfrågan. HTTP-förfrågan genererar ytterligare overhead genom att den måste generera, förhandla och upprätta anslutningen över en nätverkssocket. Det påverkar till och med den effektiva kapaciteten hos din underliggande webbserver. Den här lösningen fungerar inte bra i de flesta situationer, och ärligt talat bör den tas bort som standardbeteende på grund av dess benägenhet att missbrukas eller förvandlas till en angreppsvektor på en server bara genom vanlig trafik.

Vad är alternativen?

Det enda riktiga alternativet och den mycket bättre lösningen är att konfigurera ett vanligt cronjobb i systemet som utför skriptet wp-cron.php direkt via PHP varje minut. Detta säkerställer att alla schemalagda uppgifter verkligen utförs vid den schemalagda tidpunkten. Det bör inte heller göras via en HTTP-förfrågan utan en direkt exekvering av PHP för att undvika att hindra webbserverns kapacitet eller generera ytterligare minnesöverskott på nätverkslagret.

Hur inaktiverar jag standardbeteendet wp-cron.php?

Detta är ganska universellt och enkelt att göra. Du måste uppdatera filen wp-cronfig.php så att den innehåller följande inställning:

define('DISABLE_WP_CRON', true);
  • Du hittar vanligtvis filen wp-config.php i din webbplats katalog public_html.
  • Denna nya inställning ska läggas in i filen precis efter DB_COLLATE-databasraden som ser ut på följande sätt
define('DB_COLLATE', '');

Hur ställer jag in ett systemcronjobb?

Detta är enkelt i cPanel, om din webbhotellleverantör har aktiverat funktionen för cronjobb på ditt konto. Dokumentationen för cPanel Cron Jobs går in på mer detaljer, men i huvudsak gör du så här:

  1. Logga in på cPanel för din domän: yourdomain.tld/cpanel
  2. Inför ”cron” i snabbsökningsrutan längst upp på sidan.
  3. Klicka på ikonen ”Cron Jobs” som visas.
  • Om den inte visas har ditt konto inte Cron Jobs-funktionen aktiverad och du måste prata med din webbhotellleverantör för att få hjälp med att konfigurera cron eller byta till ett paket som innehåller Cron Jobs-funktionen.
  1. Var uppmärksam på Cron Jobs-sidan, den ger dig den exakta platsen för din binära PHP-fil. Du måste kopiera den sökvägen till kommandorutan längst ner på sidan och ändra filen som exekveras av PHP till att vara din /home/username/public_html/wp-cron.php-fil istället. Användning av den fullständiga sökvägen.
  2. Välj den första posten (”*”) för varje parameter. Detta kommer att exekvera filen wp-cron.php varje minut.
  3. Klicka på den där add cron-knappen och du är klar.

Varför är du så hård mot denna praxis, den verkar rimlig och lätt att åtgärda?

Jag anser att det är upp till de programvaruingenjörer som utvecklar vår digitala värld att inpränta en känsla av ansvar för sina produkter. WordPress är allestädes närvarande nuförtiden och med automatisk installationsprogramvara, som Softaculous, installeras WordPress på en mycket stor majoritet av webbplatserna. De installeras med standardbeteendet aktiverat, vilket i princip är en angreppsvektor på vilken server som helst. Nu när hostingbranschen är så utbredd i våra liv är det många som har WordPress-webbplatser och som inte känner till problemet förrän det lamslår deras webbplats. Standardintegrationen är helt otillräcklig och bör tas bort. I dag hittade jag bara på en server över 500 olika installationer av WordPress och såg hur en bot slog till mot varje webbplats på servern. Var och en av dessa webbplatser blev plötsligt en belastning för serverns stabilitet.

Jag inser att detta problem hanteras från fall till fall. Men med så många installationer runt om i världen skulle det vara bättre om det hanterades av WordPress än av varje enskild hostingleverantör som måste ställa in särskilda villkor på sin server för att skydda sig mot det hål som den här programvaran genererar. Kostnaden för att ta bort detta beteende och tvinga webbplatsägare att generera en systemcron bör vara grundläggande och ett meddelande placeras i WordPress administratörsgränssnitt om att schemalagda uppgifter inte kommer att exekveras förrän ett systemcronjobb har skapats på rätt sätt. Detta ligger inom mina programmeringskunskaper, så jag vet att det ligger väl inom deras.

WordPress strävar efter användarvänlighet, så deras målgrupper är de som vanligtvis vet lite om förbehåll för webbhotell. Jag tror att ansvaret här ligger helt och hållet på WordPress att åtgärda och de har tagit ställning mot det. Under tiden måste systemadministratörerna i webbhotellbranschen utstå denna fruktansvärda ”funktion” när de undersöker servrar som har tappat kontrollen på grund av att en bot kört över en standardinstallation av WordPress.