Noční můra, kterou je wp-cron.php

BY admin
|

Jedním z hlavních problémů, které mám s WordPressem, je výchozí implementace wp-cron.php. Pokud jste obeznámeni s tím, jak WordPress ve výchozím nastavení používá soubor wp-cron.php, možná budete chtít přeskočit na další část tohoto článku.

Soubor wp-cron.php je část WordPressu, která zpracovává plánované události v rámci webu WordPress. Vše, co souvisí s plánováním příspěvků nebo publikací, a vlastně cokoli, co se týká data a času, se řídí souborem wp-cron.php.

Aby soubor wp-cron.php správně fungoval, musí se spouštět často, ale ne častěji než jednou za minutu. Výchozí chování však nevyžaduje, abyste na serveru nastavili skutečnou úlohu cron na systémové úrovni. Místo toho používá metodu piggyback na každý příchozí požadavek. Když na web přijde požadavek, WordPress sám od sebe vygeneruje další požadavek do souboru wp-cron.php prostřednictvím protokolu HTTP(S). To zní docela neškodně, že?“

Proč je výchozí chování souboru wp-cron.php noční můrou?“

Výchozí metoda funguje na malém webu s velmi malým počtem návštěvníků za hodinu naprosto v pořádku. Při implementaci na středně velkém nebo větším webu nebo dokonce na webu, který je skenován roboty (což je v dnešní době velmi časté), to však znamená, že dostanete dvojnásobek jakéhokoli provozu, který právě zpracováváte. Stává se z toho rudimentární útok DDoS proti vám samotným. Je to proto, že cron je prováděn několikrát za minutu pomocí požadavku HTTP. Požadavek HTTP generuje další režii tím, že musí vygenerovat, vyjednat a navázat spojení přes síťový soket. To dokonce ovlivňuje efektivní kapacitu vašeho základního webového serveru. Toto řešení se ve většině situací neosvědčuje a upřímně řečeno by mělo být odstraněno jako výchozí chování kvůli své náchylnosti ke zneužití nebo přeměně ve vektor útoku na server jen z běžného provozu.

No a jaké jsou alternativy?

Jedinou skutečnou alternativou a mnohem lepším řešením je nakonfigurovat pravidelný systémový cronjob, který každou minutu spustí skript wp-cron.php přímo prostřednictvím PHP. Tím zajistíte, že se všechny naplánované úlohy skutečně provedou v naplánovaný čas. Nemělo by se to také provádět prostřednictvím požadavku HTTP, ale přímým spuštěním PHP, aby nedocházelo k omezování kapacity webového serveru nebo generování další paměťové zátěže na síťové vrstvě.

Jak zakázat výchozí chování wp-cron.php?

To je poměrně univerzální a jednoduché řešení. Musíte aktualizovat soubor wp-cronfig.php tak, aby obsahoval následující nastavení:

define('DISABLE_WP_CRON', true);

  • Soubor wp-config.php obvykle najdete v adresáři public_html vašeho webu.
  • Toto nové nastavení by mělo být v souboru umístěno hned za řádek DB_COLLATE databáze, který vypadá následovně
define('DB_COLLATE', '');

Jak nastavím systémovou úlohu cron?

Je to jednoduché v panelu cPanel za předpokladu, že poskytovatel hostingu povolil funkci úloh cron na vašem účtu. Dokumentace k cronovým úlohám v cPanelu je podrobnější, ale v podstatě uděláte:

  1. Přihlaste se do cPanelu pro svou doménu: yourdomain.tld/cpanel
  2. Zadejte „cron“ do pole pro rychlé vyhledávání v horní části stránky.
  3. Klikněte na ikonu „Cron Jobs“, která se zobrazí.
  • Pokud se nezobrazí, váš účet nemá povolenou funkci Cron Jobs a budete se muset obrátit na svého poskytovatele hostingu, aby vám pomohl s nastavením cronu nebo s přechodem na balíček, který funkci Cron Jobs obsahuje.
  1. Věnujte pozornost stránce Cron Jobs, poskytne vám přesné umístění vaší binární jednotky PHP. Tuto cestu budete muset zkopírovat do příkazového pole v dolní části stránky a změnit soubor spouštěný PHP tak, aby místo něj byl váš soubor /home/username/public_html/wp-cron.php. Použití celé cesty.
  2. Zvolte první položku („*“) pro každý parametr. Tím se každou minutu spustí soubor wp-cron.php.
  3. Klikněte na tlačítko přidat cron a je hotovo.

Proč jste na tuto praxi tak přísní, zdá se rozumná a snadno napravitelná?

Myslím si, že je na softwarových inženýrech, kteří vyvíjejí náš digitální svět, aby si vtiskli pocit odpovědnosti za své produkty. WordPress je v dnešní době všudypřítomný a díky automatickému instalačnímu softwaru, jako je Softaculous, se WordPress instaluje na naprostou většinu webů. Ty jsou instalovány s povoleným výchozím chováním, což je v podstatě vektor útoku na jakýkoli server. Vzhledem k tomu, že hostingový průmysl je nyní v našem životě tak rozšířený, mnoho lidí má weby WordPress a o tomto problému neví, dokud neochromí jejich web. Výchozí integrace je velmi nevhodná a měla by být odstraněna. Dnes jsem jen na jednom serveru našel přes 500 různých instalací WordPressu a sledoval, jak bot zasáhl každý web na serveru. Každý z těchto webů se rázem stal přítěží pro stabilitu serveru.

Uvědomuji si, že tento problém se řeší případ od případu. Nicméně při takovém množství instalací po celém světě by to měl řešit spíše WordPress než každý jednotlivý poskytovatel hostingu, který musí na svém serveru nastavovat speciální podmínky pro ochranu před dírou, kterou tento software vytváří. Náklady na odstranění tohoto chování a donucení majitelů stránek k vytvoření systémového cronu by měly být základní a v administračním rozhraní WordPressu by mělo být umístěno upozornění, že naplánované úlohy nebudou prováděny, dokud nebude systémová úloha cronu řádně vytvořena. To je v rámci mých programátorských schopností, takže vím, že je to i v jejich silách.

WordPress si klade za cíl snadné používání, takže jeho cílovými zákazníky jsou ti, kteří obvykle vědí jen málo o výhradech hostingu. Domnívám se, že zodpovědnost zde leží plně na WordPressu, který to musí napravit a postavil se proti tomu. Systémoví administrátoři v oblasti hostingu zatím musí tuto příšernou „funkci“ trpět při zkoumání serverů, které se vymkly kontrole kvůli botovi spuštěnému přes výchozí instalaci WordPressu.