A rémálom, ami a wp-cron.php

BY admin
|

Az egyik legnagyobb gondom a WordPress-szel az alapértelmezett wp-cron.php implementáció. Ha ismered, hogy a WordPress alapértelmezés szerint hogyan használja a wp-cron.php-t, akkor érdemes átugranod a cikk következő részét.

A wp-cron.php fájl a WordPress azon része, amely a WordPress webhelyen belüli ütemezett eseményeket kezeli. Bármi, aminek köze van a bejegyzések vagy publikációk ütemezéséhez, és tényleg minden dátummal/idővel kapcsolatos dolgot a wp-cron.php fájl szabályoz.

Azért, hogy a wp-cron.php megfelelően működjön, gyakran kell végrehajtani, de legfeljebb percenként egyszer. Az alapértelmezett viselkedés azonban nem igényli, hogy valódi rendszerszintű cron feladatot állítson be a szerveren. Ehelyett egy piggyback módszert használ minden bejövő kérésre. Amikor egy kérés érkezik az oldalra, a WordPress egy további kérést generál magától a wp-cron.php fájlba HTTP(S)-en keresztül. Ez elég ártalmatlanul hangzik, igaz?

Miért rémálom az alapértelmezett wp-cron.php viselkedése?

Az alapértelmezett módszer tökéletesen működik egy kis webhelyen, ahol óránként nagyon kevés látogató fordul meg. Azonban, ha egy közepes vagy nagyobb webhelyen vagy akár egy olyan webhelyen, amelyet botok vizsgálnak (ami manapság nagyon gyakori), ez azt jelenti, hogy kétszeresét kapod annak a forgalomnak, amit jelenleg kezelsz. Ez egy kezdetleges DDoS-támadássá válik önmaga ellen. Ez azért van, mert a cron percenként többször is végrehajtódik egy HTTP-kérés segítségével. A HTTP-kérés további többletköltséget generál azáltal, hogy létre kell hoznia, tárgyalnia és létrehoznia a kapcsolatot egy hálózati aljzaton keresztül. Ez még a mögöttes webkiszolgáló tényleges kapacitását is befolyásolja. Ez a megoldás a legtöbb helyzetben nem áll jól, és őszintén szólva el kellene távolítani alapértelmezett viselkedésként, mivel hajlamos arra, hogy visszaéljenek vele, vagy támadási vektorrá váljon egy szerver ellen pusztán a rendszeres forgalomból.

Hát, mik az alternatívák?

Az egyetlen valódi alternatíva és a sokkal jobb megoldás egy rendszeres rendszer-cronjob beállítása, amely a wp-cron.php szkriptet közvetlenül a PHP-n keresztül hajtja végre percenként. Ez biztosítja, hogy minden ütemezett feladat valóban a tervezett időpontban végrehajtásra kerüljön. Szintén nem HTTP-kérésen keresztül, hanem a PHP közvetlen végrehajtásán keresztül kell elvégezni, hogy ne akadályozza a webszerver kapacitását, illetve ne generáljon további memóriaterhelést a hálózati rétegen.

Hogyan tiltsam le az alapértelmezett wp-cron.php viselkedését?

Ez elég univerzális és egyszerűen elvégezhető. Frissítened kell a wp-cronfig.php fájlodat, hogy tartalmazza a következő beállítást:

define('DISABLE_WP_CRON', true);
  • A wp-config.php fájlt általában a webhelyed public_html könyvtárában találod.
  • Ezt az új beállítást közvetlenül a DB_COLLATE adatbázis sor után kell elhelyezni a fájlban, amely a következőképpen néz ki
define('DB_COLLATE', '');

Hogyan állíthatok be egy rendszer cron feladatot?

Ez egyszerű a cPanelben, feltéve, hogy a tárhelyszolgáltató engedélyezte a cron feladat funkciót a fiókodban. A cPanel Cron munkák dokumentációja részletesebben kifejti, de lényegében a következőket kell tenned:

  1. Login a cPanelbe a domainedhez: yourdomain.tld/cpanel
  2. Az oldal tetején található gyorskeresőbe írd be a “cron” szót.
  3. Kattints a megjelenő “Cron munkák” ikonra.
  • Ha nem jelenik meg, akkor a fiókjában nincs engedélyezve a Cron Jobs funkció, és a tárhelyszolgáltatójával kell beszélnie a cron beállításához, vagy olyan csomagra kell váltania, amely tartalmazza a Cron Jobs funkciót.
  1. Figyeljen a Cron Jobs oldalra, az megadja a PHP binárisának pontos helyét. Ezt az elérési utat be kell másolnia az oldal alján található parancsdobozba, és a PHP által végrehajtott fájlt úgy kell módosítania, hogy az a /home/felhasználónév/public_html/wp-cron.php fájl legyen helyette. A teljes elérési útvonal használata.
  2. Válassza ki az első bejegyzést (“*”) az egyes paramétereknél. Ez minden percben végrehajtja a wp-cron.php fájlt.
  3. Kattints arra a cron hozzáadása gombra, és kész is vagy.

Miért vagy ilyen szigorú ezzel a gyakorlattal, hiszen ésszerűnek és könnyen javíthatónak tűnik?

Hiszem, hogy a digitális világunkat fejlesztő szoftverfejlesztőkön múlik, hogy felelősségérzetet sugalljanak maguknak a termékeikért. A WordPress manapság mindenütt jelen van, és az olyan automatikus telepítő szoftverekkel, mint a Softaculous, a WordPress a webhelyek nagyon nagy többségére települ. Ezeket az alapértelmezett viselkedés engedélyezésével telepítik, ami lényegében egy támadási vektor minden szerveren. Most, hogy a tárhelyipar annyira elterjedt az életünkben, sok embernek van WordPress-oldala, és nem tudnak erről a problémáról, amíg meg nem bénítja az oldalukat. Az alapértelmezett integráció fájdalmasan nem megfelelő, és el kellene távolítani. Ma csak egy szerveren több mint 500 különböző WordPress-telepítést találtam, és végignéztem, ahogy egy bot minden egyes webhelyet megtámad a szerveren. Minden egyes ilyen webhely hirtelen a szerver stabilitását veszélyeztető tényezővé vált.

Tudom, hogy ezt a problémát eseti alapon kezelik. Azonban ennyi telepítéssel világszerte jobb lenne, ha ezt a WordPress kezelné, nem pedig minden egyes tárhelyszolgáltató, akinek speciális feltételeket kell beállítania a szerverén, hogy védekezzen az ellen a lyuk ellen, amit ez a szoftver generál. Ennek a viselkedésnek a megszüntetésének és a webhelytulajdonosok rendszer-cron létrehozására való kényszerítésének költségei alapszintűek kellene, hogy legyenek, és a WordPress admin felületén belül el kellene helyezni egy értesítést, hogy az ütemezett feladatok nem fognak végrehajtódni, amíg a rendszer-cron feladatot nem hozzák létre megfelelően. Ez az én programozási képességeimen belül van, így tudom, hogy az övékén is.

A WordPress célja az egyszerű használat, így a célközönségük azok a fogyasztók, akik jellemzően keveset tudnak a tárhely-előrejelzésekről. Úgy gondolom, hogy a felelősség itt teljes mértékben a WordPress-t terheli a javítás, és ők foglaltak állást ez ellen. Addig is a rendszeradminisztrátoroknak a tárhelyiparban el kell szenvedniük ezt a szörnyű “funkciót”, amikor olyan szervereket vizsgálnak, amelyek egy alapértelmezett WordPress telepítésen keresztül futó bot miatt kiestek az ellenőrzés alól.