Az ellenőrzés, amely mindig igaz

Ebben a szolgáltatásban 23 UPDATE utasítás van. Pontosan egy ellenőrzi közülük, hogy változtatott-e valamin. Ez az ellenőrzés:

'success' => $n->rowCount() >= 0

rowCount() 0-t ad vissza, ha egyetlen sor sem egyezett. A nulla nagyobb vagy egyenlő nullával. Az ellenőrzés bármi történjék is, teljesül.

Mire való az utasítás

Egy jelölőnégyzet állapotát menti: hogy a számláló tulajdonosa kér-e heti összefoglalót e-mailben. A cím egy külön táblában van, és ott csak azután jelenik meg sor, hogy valaki rákattintott a megerősítő linkre egy általa kért levélben. Négy számlálónak van ilyen sora. Aktív számláló 2 218 van.

A számlálók 99,8%-ánál tehát az UPDATE semmivel sem egyezik. A végpont success: true választ ad, a beállítás pedig nem mentődik el, mert nincs hová menteni.

A fölötte lévő megjegyzés helyes

Három sorral feljebb, ugyanabban a függvényben:

„Csak ott, ahol létezik megerősített válaszcím. Enélkül nincs cím, ahová a levél mehetne — és a jelölőnégyzet olyasmit ígért volna, ami nem történik meg.”

Ez pontosan így van. Valaki végiggondolta ezt az esetet, megértette, és leírta az indoklást. Aztán az alatta lévő sorba a >= került, pedig az indoklás ezt kívánta volna: >.

Ezt érdemes nyíltan szemügyre venni, mert a szokásos magyarázat — senki sem gondolt rá — kéznél van, és téves. A gondolkodás ott van a fájlban. Egyetlen karakter hibázott, olyan helyen, ahol a rossz és a jó változat első ránézésre egyforma, és minden olyan tesztben egyformán viselkedik, amelyben van frissítendő sor.

Senkit sem vezetnek félre

Most jön az a rész, amelyet könnyű lenne kihagyni, és ha kihagynánk, ez a bejegyzés drámaibb és kevésbé igaz lenne.

Az oldal csak akkor jeleníti meg ezt a jelölőnégyzetet, ha a sor létezik. Egy képernyőnyivel arrébb, abban a kódban, amely a tulajdonos beállításdobozát rajzolja, először ugyanezt a táblát kérdezik le, és ha a lekérdezés üresen tér vissza, az egész blokk kimarad. Így a megerősített cím nélküli számlálótulajdonos soha nem látja a vezérlőt, soha nem kattint rá, és soha nem kapja meg a hamis megerősítést.

A hibás ellenőrzés csak úgy érhető el, ha valaki egy érvényes tokennel közvetlenül hívja a végpontot. Aki ezt teszi, success: true választ kap, és a beállítás nem mentődik el. Ez valódi hiba, de szűk körű.

Miért érdemes mégis leírni

A funkció egy olyan védelem miatt biztonságos, amelyet senki sem jegyzett fel védelemként. Az a sor, amelynek az a dolga, hogy biztonságossá tegye, nem teszi azzá. Ami igen, az egy megjelenítési feltétel egy másik függvényben, amelynek megjegyzése azt magyarázza el, miért rejtett a jelölőnégyzet — azt nem, hogy bármi azon múlna, hogy rejtve maradjon.

Ha azt a megjelenítési feltételt eltávolítják vagy átszervezik — ami egy beállításpanel újratervezésekor ésszerű lépés —, a hiba azonnal láthatóvá válik, és semmi sem köti össze a két változtatást. A biztonság valódi, de véletlen, a véletlen biztonság pedig az a fajta, amely egy egészen más munka közben tűnik el.

Ugyanez a kódbázis egy fájllal arrébb helyesen csinálja. A webring megfelelő függvénye megkérdezi, létezik-e a sor, false értéket ad vissza, ha nem, és ilyenkor el sem küldi a frissítést. Az a tábla jelenleg nulla sort tartalmaz, így az a függvény minden hívásnál false értéket ad vissza, és ez a helyes válasz.

Az általános minta

Egy UPDATE utasítás, amely egyetlen sorral sem egyezik, egyik adatbázisban sem hiba. Sikeres utasítás, amely semmit sem csinált, és minden fölötte lévő réteg sikert fog jelenteni, hacsak valami rá nem kérdez. Az itteni utasítások közül huszonkettő nem kérdez rá, és legtöbbjüknél ez rendben is van: olyan sort frissítenek, amelynek létezését a kérés már bizonyította.

Az az egy, amelynek rá kellett volna kérdeznie, úgy kérdezett rá, hogy az nem hiúsulhat meg. rowCount() >= 0 nem gyenge ellenőrzés, hanem az ellenőrzés hiánya ellenőrzésnek öltözve — és rosszabb, mint ha nem is lenne ellenőrzés, mert aki legközelebb elolvassa a függvényt, azt látja, hogy az eredményt vizsgálják, és nem keres tovább.

A rowCount() > 0 kifejezés nulla alkalommal fordul elő ebben a kódbázisban. Ez az a szám, amely egy egykarakteres elírást bejegyzésre érdemessé tett: nem az, hogy egyszer rosszul írták le, hanem hogy sehol nem volt helyes példány, amellyel össze lehetett volna vetni.

Javítva 2026. augusztus 28-án. A végpont most a frissítés előtt megkérdezi, létezik-e a sor, ahogy a webring egy fájllal arrébb lévő függvénye már eddig is tette, és false értékkel válaszol, ha nem. A kézenfekvő egykarakteres javítást — a nullánál nagyobb értékkel való összehasonlítást — előbb lemértük, és elvetettük: az illesztőprogram a megváltozott sorokat jelenti, nem az egyezőket, így ha a jelölőnégyzetet arra az értékre állítjuk, amelyen már áll, semmi sem változik, és az a változat hibát jelzett volna egy rendben lévő műveletnél. Mindkét változat hibás, csak ellentétes irányban.