Painajainen, joka on wp-cron.php

BY admin
|

Yksi suurimmaksi murheenkryyniksi WordPressin kanssa on muodostunut oletusarvoinen wp-cron.php-toteutus. Jos olet perehtynyt siihen, miten WordPress käyttää wp-cron.php:tä oletusarvoisesti, kannattaa ehkä siirtyä tämän artikkelin seuraavaan osaan.

Tiedosto wp-cron.php on WordPressin osa, joka käsittelee ajastettuja tapahtumia WordPress-sivuston sisällä. Kaikkea, mikä liittyy postausten tai julkaisujen aikatauluttamiseen ja oikeastaan kaikkeen päivämäärään/aikaan liittyvään, ohjataan wp-cron.php-tiedostolla.

Jotta wp-cron.php toimisi kunnolla, se on suoritettava usein, mutta korkeintaan kerran minuutissa. Oletuskäyttäytyminen ei kuitenkaan edellytä todellisen järjestelmätason cron-työn asettamista palvelimellesi. Sen sijaan se käyttää piggyback-menetelmää jokaiseen saapuvaan pyyntöön. Kun sivustolle tulee pyyntö, WordPress luo itsestään lisäpyynnön wp-cron.php-tiedostoon HTTP(S):n kautta. Kuulostaa aika harmittomalta, eikö?

Miksi wp-cron.php:n oletuskäyttäytyminen on painajainen?

Vakiomenetelmä toimii täysin hyvin pienellä sivustolla, jolla on hyvin vähän kävijöitä tunnissa. Kuitenkin, kun se toteutetaan keskisuurella tai suuremmalla sivustolla tai jopa sivustolla, jota botit tutkivat (mikä on nykyään hyvin yleistä), tämä tarkoittaa, että saat kaksinkertaisen kertauksen riippumatta siitä, mitä liikennettä tällä hetkellä käsittelet. Siitä tulee alkeellinen DDoS-hyökkäys itseäsi vastaan. Tämä johtuu siitä, että cron suoritetaan useita kertoja minuutissa HTTP-pyynnön avulla. HTTP-pyyntö aiheuttaa ylimääräistä ylikuormitusta, koska sen on luotava, neuvoteltava ja muodostettava yhteys verkon pistorasian kautta. Se vaikuttaa jopa taustalla olevan verkkopalvelimesi tehokkaaseen kapasiteettiin. Tämä ratkaisu ei pärjää useimmissa tilanteissa hyvin, ja rehellisesti sanottuna se pitäisi poistaa oletuskäyttäytymisenä, koska se on altis väärinkäytölle tai muuttuu hyökkäysvektoriksi palvelimelle pelkän tavanomaisen liikenteen vuoksi.

Mitkä ovat vaihtoehdot?

Ainoa todellinen vaihtoehto ja paljon parempi ratkaisu on konfiguroida säännöllinen järjestelmän cronjob, joka suorittaa wp-cron.php-skriptin suoraan PHP:n kautta joka minuutti. Näin varmistetaan, että kaikki ajoitetut tehtävät todella suoritetaan ajoitettuna ajankohtana. Sitä ei myöskään pitäisi tehdä HTTP-pyynnön kautta, vaan suorana PHP:n suorittamisena, jotta vältetään verkkopalvelimen kapasiteetin haittaaminen tai ylimääräisen muistin ylikuormituksen tuottaminen verkkokerroksessa.

Miten poistan wp-cron.php:n oletuskäyttäytymisen käytöstä?

Tämä on melko yleispätevää ja yksinkertaista tehdä. Sinun täytyy päivittää wp-cronfig.php-tiedostosi sisältämään seuraava asetus:

define('DISABLE_WP_CRON', true);
  • Löydät wp-config.php-tiedostosi yleensä sivustosi public_html-hakemistosta.
  • Tämä uusi asetus tulisi laittaa tiedostoon heti DB_COLLATE-tietokantarivin jälkeen, joka näyttää seuraavalta
define('DB_COLLATE', '');

Miten asetan järjestelmän cron-työn?

Tämä on yksinkertaista cPanelissa, olettaen, että hosting-palveluntarjoajasi on ottanut cron-työominaisuuden käyttöön tililläsi. cPanelin Cron Jobs -dokumentaatiossa kerrotaan tarkemmin, mutta pohjimmiltaan teet näin:

  1. Kirjaudu cPaneliin verkkotunnuksellesi: yourdomain.tld/cpanel
  2. Syötä ”cron” sivun yläreunan lähellä olevaan pikahakukenttään.
  3. Klikkaa avautuvaa ”Cron Jobs” -kuvaketta.
  • Jos se ei näy, tililläsi ei ole Cron Jobs -ominaisuutta käytössä, ja sinun täytyy keskustella hosting-palveluntarjoajasi kanssa saadaksesi apua cronin määrittämisessä tai vaihtaaksesi pakettiin, joka sisältää Cron Jobs -ominaisuuden.
  1. Katso tarkasti Cron Jobs -sivua, se antaa sinulle PHP- binäärisi tarkan sijainnin. Sinun on kopioitava tämä polku sivun alareunassa olevaan komentoruutuun ja muutettava PHP:n suorittama tiedosto niin, että se on sen sijaan /home/käyttäjätunnus/julkinen_html/wp-cron.php-tiedostosi. Käyttämällä koko polkua.
  2. Valitse kunkin parametrin ensimmäinen merkintä (”*”). Tämä suorittaa wp-cron.php-tiedoston minuutin välein.
  3. Klikkaa tuota Lisää cron-painiketta ja olet valmis.

Miksi olet niin ankara tälle käytännölle, se vaikuttaa kohtuulliselta ja helposti korjattavalta?

Olen sitä mieltä, että digitaalista maailmaamme kehittävien ohjelmistosuunnittelijoiden tehtävänä on iskostaa itselleen vastuuntuntoa tuotteistaan. WordPress on nykyään kaikkialla läsnä ja Softaculousin kaltaisten automaattisten asennusohjelmistojen avulla WordPress asennetaan hyvin suureen osaan sivustoja. Ne asennetaan niin, että oletuskäyttäytyminen on käytössä, mikä on pohjimmiltaan hyökkäysvektori mille tahansa palvelimelle. Nyt kun hosting-ala on niin yleistä elämässämme, monilla ihmisillä on WordPress-sivustoja eivätkä he tiedä tästä ongelmasta, ennen kuin se rampauttaa heidän sivustonsa. Oletusintegrointi on erittäin riittämätön, ja se pitäisi poistaa. Pelkästään yhdellä palvelimella löysin tänään yli 500 erilaista WordPress-asennusta ja katselin, kun botti iski jokaiseen palvelimella olevaan sivustoon. Jokaisesta näistä sivustoista tuli yhtäkkiä rasite palvelimen vakaudelle.

Ymmärrän, että tätä ongelmaa käsitellään tapauskohtaisesti. Koska asennuksia on kuitenkin niin paljon ympäri maailmaa, olisi parempi, että siihen puuttuisi WordPress eikä jokainen yksittäinen hosting-palveluntarjoaja, joka joutuu asettamaan palvelimelleen erityisehtoja suojautuakseen tämän ohjelmiston synnyttämältä reiältä. Kustannusten, jotka aiheutuvat tämän käyttäytymisen poistamisesta ja sivuston omistajien pakottamisesta luomaan järjestelmän cron-työ, pitäisi olla perustaso ja WordPressin hallintakäyttöliittymään tulisi sijoittaa ilmoitus, jonka mukaan ajastettuja tehtäviä ei suoriteta, ennen kuin järjestelmän cron-työ on luotu asianmukaisesti. Tämä kuuluu ohjelmointitaitojeni piiriin, joten tiedän, että se kuuluu hyvin heidän taitoihinsa.

WordPress pyrkii helppokäyttöisyyteen, joten sen kohderyhmänä ovat kuluttajat, jotka tyypillisesti tietävät vain vähän hosting-varoituksista. Uskon, että vastuu tässä on täysin WordPressin korjattavana ja he ovat ottaneet siihen kantaa. Sillä välin isännöintialan järjestelmänvalvojat joutuvat kärsimään tästä kauheasta ”ominaisuudesta” tutkiessaan palvelimia, jotka ovat karanneet käsistä oletusarvoisen WordPress-asennuksen päällä pyörivän botin takia.