Miért használjon sablonokat?
Miért érdemes sablonrendszert használni a PHP-ban?
Miért használjunk sablonrendszert a PHP-ban, amikor a PHP maga is sablonnyelv?
Először is, foglaljuk össze röviden ennek a nyelvnek a történetét, amely tele van érdekes fordulatokkal. Az egyik első HTML-oldalak generálására használt programozási nyelv a C nyelv volt. Hamarosan kiderült azonban, hogy erre a célra használni nem praktikus. Rasmus Lerdorf ezért megalkotta a PHP-t, amely megkönnyítette a dinamikus HTML generálását a C nyelvvel a háttérben. A PHP-t eredetileg templating nyelvnek tervezték, de idővel további funkciókkal bővült, és teljes értékű programozási nyelvvé vált.
Ennek ellenére továbbra is templating nyelvként működik. Egy PHP-fájl tartalmazhat egy HTML-oldalt, amelyben a
változókat a következő módon adjuk ki <?= $foo ?>, stb.
A PHP történetének korai szakaszában jött létre a Smarty sablonrendszer, amelynek célja a megjelenés (HTML/CSS) és az alkalmazási logika szigorú szétválasztása volt. Szándékosan korlátozottabb nyelvet biztosított, mint maga a PHP, így például egy fejlesztő nem tudott egy sablonból adatbázis-lekérdezést készíteni stb. Másrészt további függőséget jelentett a projektekben, növelte azok összetettségét, és a programozóknak egy új Smarty nyelvet kellett megtanulniuk. Ezek az előnyök ellentmondásosak voltak, és továbbra is a sima PHP-t használták a sablonokhoz.
Idővel a sablonrendszerek kezdtek hasznosnak bizonyulni. Olyan fogalmakat vezettek be, mint az öröklés, a sandbox mód és egy sor más funkció, amelyek jelentősen leegyszerűsítették a sablonkészítést a tiszta PHP-hoz képest. A biztonság témája, az olyan sebezhetőségek létezése , mint az XSS, és a menekülés szükségessége előtérbe került. A sablonrendszerek bevezették az automatikus mentést, hogy kiküszöböljék annak kockázatát, hogy a programozó elfelejtse és komoly biztonsági rést hozzon létre (rövidesen látni fogjuk, hogy ennek vannak bizonyos buktatói).
Ma a sablonrendszerek előnyei messze meghaladják a bevezetésükkel járó költségeket. Ezért van értelme használni őket.
Miért jobb a Latte, mint a Twig vagy a Blade?
Számos oka van – néhány kellemes, mások pedig mérhetetlenül hasznosak. A Latte a kellemes és a hasznos kombinációja.
Először is, a kellemes: A Latte szintaxisa megegyezik a PHP-ével. Az egyetlen különbség a címkék jelölésében van, a
<?= és a ?> helyett a rövidebb { és } jelöléseket részesíti
előnyben. Ez azt jelenti, hogy nem kell új nyelvet tanulnia. A képzési költségek minimálisak. A legfontosabb, hogy a
fejlesztés során nem kell folyamatosan „váltogatni“ a PHP és a sablonnyelv között, mivel mindkettő ugyanaz. Ez
ellentétben a Twig sablonokkal, amelyek a Python nyelvet használják, így a programozó kénytelen két különböző nyelv
között váltani.
Most a mérhetetlenül hasznos ok: Minden sablonrendszer, mint például a Twig, a Blade vagy a Smarty, úgy
fejlődött, hogy tartalmazzon XSS elleni védelmet az automatikus escaping formájában.
Pontosabban a htmlspecialchars() függvény automatikus meghívása. A Latte készítői azonban rájöttek, hogy ez
egyáltalán nem jó megoldás. A dokumentum különböző részei ugyanis különböző escaping módszereket igényelnek.
A naiv automatikus szcenírozás veszélyes funkció, mert hamis biztonságérzetet kelt.
Ahhoz, hogy az automatikus menekítés működőképes és megbízható legyen, fel kell ismernie, hogy a dokumentumban hol történik az adatok kimenete (ezeket nevezzük kontextusoknak), és ennek megfelelően kell kiválasztania a menekítési funkciót. Ezért kontextusfüggőnek kell lennie. És ez az, amire a Latte képes. Megérti a HTML-t. A sablont nem csak egy karaktersorozatként érzékeli, hanem megérti, hogy mik a címkék, attribútumok stb. Ezért másképp lép el a HTML-szövegben, a HTML-címkéken belül, a JavaScriptben stb.
A Latte az első és egyetlen PHP sablonrendszer, amely kontextusfüggő escapinggel rendelkezik. Ez az egyetlen igazán biztonságos sablonrendszer.
És egy másik kellemes ok: Mivel a Latte érti a HTML-t, más nagyon kellemes funkciókat is kínál. Például az n:attribútumok. Vagy a linkek ellenőrzésének lehetőségét. És még sok minden mást.
Mi az a menekülés?
Az escaping egy olyan folyamat, amely során a különleges jelentésű karaktereket megfelelő szekvenciákkal
helyettesítjük, amikor az egyik karakterláncot egy másikba illesztjük, hogy megakadályozzuk a nem kívánt hatásokat vagy
hibákat. Például, amikor egy olyan karakterláncot illesztünk be HTML-szövegbe, amelyben a < karakter
különleges jelentéssel bír, mivel egy tag elejét jelzi, a megfelelő szekvenciával helyettesítjük, ami a
< HTML-egység. Ez lehetővé teszi a böngésző számára a < szimbólum helyes
megjelenítését.
Egy egyszerű példa a PHP-kód írásakor a közvetlen menekülésre, amikor idézőjelet illesztünk be egy karakterláncba úgy, hogy egy backslash-t helyezünk elé.
Az escapinget részletesebben a Hogyan védekezzünk az XSS ellen című fejezetben tárgyaljuk.
Végrehajtható-e adatbázis-lekérdezés egy Latte sablonból?
A sablonokban olyan objektumokkal lehet dolgozni, amelyeket a programozó átad nekik. Ha a programozó úgy akarja, átadhat egy adatbázis-objektumot a sablonhoz, és lekérdezést végezhet. Ha ezt szándékukban áll megtenni, nincs okunk megakadályozni őket ebben.
Más a helyzet, ha az ügyfeleknek vagy külső programozóknak akarja megadni a sablonok szerkesztésének lehetőségét. Ebben az esetben semmiképpen sem szeretné, ha hozzáférnének az adatbázishoz. Természetesen nem fogod átadni az adatbázis-objektumot a sablonhoz, de mi van akkor, ha az egy másik objektumon keresztül érhető el? A megoldás a sandbox mód, amely lehetővé teszi annak meghatározását, hogy a sablonokban milyen metódusok hívhatók meg. Ennek köszönhetően nem kell aggódnia a biztonsági rések miatt.
Mik a fő különbségek az olyan templating rendszerek között, mint a Latte, a Twig és a Blade?
Az olyan templating rendszerek, mint a Latte, a Twig és a Blade közötti különbségek elsősorban a szintaxisukban, a biztonságukban és a keretrendszerekkel való integrációjukban rejlenek:
- Latte: PHP nyelvi szintaxist használ, így könnyebben megtanulható és használható. Kiváló védelmet nyújt az XSS-támadások ellen.
- Twig: Python-szerű szintaxist használ, ami teljesen eltér a PHP nyelvtől. Kontextus megkülönböztetés nélkül menekül. Jól integrálható a Symfony keretrendszerrel.
- Blade: a PHP és az egyéni szintaxis keverékét használja. A kontextus megkülönböztetése nélkül menekül. Szorosan integrálódik a Laravel funkcióiba és ökoszisztémájába.
Megéri a vállalatoknak templating rendszert használni?
Először is, a képzéssel, a használattal és az általános előnyökkel kapcsolatos költségek jelentősen eltérnek a rendszertől függően. A Latte templating rendszer a PHP szintaxis használatának köszönhetően nagyban leegyszerűsíti a tanulást az ezen a nyelven már jártas programozók számára. Egy programozónak általában néhány óra alatt sikerül kellőképpen megismerkednie a Latte-tel, ami csökkenti a képzési költségeket, felgyorsítja a technológia átvételét és – ami a legfontosabb – a mindennapi használat hatékonyságát.
Emellett a Latte magas szintű védelmet nyújt az XSS sebezhetőséggel szemben az egyedülálló, kontextustudatos escaping technológiának köszönhetően. Ez a védelem kulcsfontosságú a webalkalmazások biztonságának biztosításához és a felhasználókat vagy a vállalati adatokat veszélyeztető támadások kockázatának minimalizálásához. A webalkalmazások biztonsága a vállalat jó hírnevének megőrzése szempontjából is fontos. A biztonsági problémák az ügyfelek bizalmának elvesztéséhez vezethetnek, és ronthatják a vállalat hírnevét a piacon.
A Latte használata csökkenti az általános fejlesztési és karbantartási költségeket is, mivel mindkettő egyszerűbbé válik. Ezért egy templating rendszer használata mindenképpen megéri.
Befolyásolja-e a Latte a webes alkalmazások teljesítményét?
Bár a Latte sablonok feldolgozása gyors, ez a szempont nem igazán számít. Ennek oka, hogy a fájlok elemzése csak egyszer történik meg az első megjelenítés során. Ezután PHP-kóddá fordítják le őket, a lemezen tárolják, és minden következő kérésnél újbóli fordítás nélkül futtatják őket.
Ez így működik a termelési környezetben. A fejlesztés során a Latte sablonok minden alkalommal újrafordításra kerülnek, amikor tartalmuk megváltozik, így a fejlesztő mindig az aktuális verziót látja.