Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: registrovany123 02. 06. 2025, 06:17:54
-
Nikdy jsem v PHP nedělal, až poslední 2-3 roky jsem se naučil Vue a React, a následně jsem měl možnost něco dělat v PHP a jsem celkem některými věcmi překvapen.
Předně, mě je úplně jasné, že v tomhle jazyce se na webových projektech nachází napsaný totální binec, s mixováním php kódu a template, jak jsem to viděl, kde ještě ke věcmu místo aby autoři kódu v templates používali shorthands, tak tam dávají samé echo.
Ale.
Když si dávám pozor, abych měl PHP kód měl nahoře a HTML kód dole, a v tom HTML kódu používal pouze shorthands, tak to není méně přehledné, než když napíšu kód třeba v Reactu nebo ve Vue.
Ukázkový kód:
<?php
// Connect to SQLite
$db = new PDO('sqlite:items.db');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
// Define order options as indexed array
$orderOptions = ['name DESC', 'price DESC'];
// Get filter and selected order index
$filter = isset($_GET['filter']) ? $_GET['filter'] : '';
$orderIndex = (isset($_GET['order']) && is_numeric($_GET['order']) && isset($orderOptions[$_GET['order']]))
? (int)$_GET['order']
: null;
// Build SQL
$sql = "SELECT * FROM items WHERE 1=1 AND (:filter IS NULL OR name LIKE :filter)";
$params = [];
$params[':filter'] = $filter !== '' ? "%$filter%" : null;
if ($orderIndex !== null) {
$sql .= " ORDER BY " . $orderOptions[$orderIndex];
}
// Fetch items
$stmt = $db->prepare($sql);
$stmt->execute($params);
$items = $stmt->fetchAll(PDO::FETCH_ASSOC);
?>
<!DOCTYPE html>
<html>
<head>
<title>Item List</title>
</head>
<body>
<h1>Items</h1>
<form method="get">
<input type="text" name="filter" value="<?= $filter ?>" placeholder="Filter by name">
<select name="order">
<option value="">-- Order by --</option>
<option value="0" <?= $orderIndex === 0 ? 'selected' : '' ?>>Name ↓</option>
<option value="1" <?= $orderIndex === 1 ? 'selected' : '' ?>>Price ↓</option>
</select>
<button type="submit">Apply</button>
</form>
<table>
<thead>
<tr>
<th>ID</th><th>Name</th><th>Price</th>
</tr>
</thead>
<tbody>
<?php foreach ($items as $item): ?>
<tr>
<td><?= $item['id'] ?></td>
<td><?= $item['name'] ?></td>
<td><?= $item['price'] ?></td>
</tr>
<?php endforeach; ?>
</tbody>
</table>
</body>
</html>
V Reactu.js by to bylo složitější, bylo by napsáno víc. Navíc, hrabal jsem se teď v DokuWiki zdrojácích, a jsem celkem překvapen, že je to celkem přehledné - a žádný framework to nemá.
Jediné co mi vadí je poněkud obstaróžní práce s fragmenty:
<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>
Kde v Raactu bych to měl o něco hezčí:
<NavButton text="Ahoj světe" href="page2.php">
No ale zase za cenu náročnější konfigurace, no a musel bych si napsat ten backend.
-
A ještě mi vadí další věc, že v PHP je nějaká kultura abuzu ECHO, viz úryvek z pluginu v DokuWiki:
echo '<dt>';
echo '<span class="datetime">' . hsc($dt) . '</span>';
echo '<span class="log">';
echo '<span class="msg">' . hsc($msg) . '</span>';
echo '<span class="file">' . hsc($file) . '</span>';
echo '</span>';
echo '</dt>';
Který by šel přitom napsat jako
echo <<<HTML
<dt>
<span class="datetime">$dt</span>
<span class="log">
<span class="msg">$msg</span>
<span class="file">$file</span>
</span>
</dt>
HTML;
-
Který by šel přitom napsat jako
echo <<<HTML
<dt>
<span class="datetime">$dt</span>
<span class="log">
<span class="msg">$msg</span>
<span class="file">$file</span>
</span>
</dt>
HTML;
To taky není nejlepší. Když už, tak echo do HTML:
<html>
<dt>
<span class="datetime"><?= $dt ?></span>
<span class="log">
<span class="msg"><?= $msg ?></span>
<span class="file"><?= $file ?></span>
</span>
</dt>
</html>
Ten úryvek z pluginu je prostě prasácký styl psaní z doby tak někdy PHP 4.
-
$filter = isset($_GET['filter']) ? $_GET['filter'] : '';
Co když tam někdo předá pole? Když do URL dám filter[]=foo, je tam pole. (BTW, v kombinaci se zapnutým zobrazení chyb je to často snadný způsob, jak trošku analyzovat cizí kód.)
Vhodný framework (nevím přesně situaci u PHP) to nejspíš zvládne ošetřit, včetně třeba ověření is_numeric u dalšího
<td><?= $item['name'] ?></td>
To je učebnicová ukázka HTML injection, a tedy XSS, ne? Frameworky to typicky z velké části řeší, byť třeba u odkazů (kam může přijít třeba javascript:alert(location.href)) si je stále někdy potřeba dát pozor. (I když to asi může řešit CSP.)
<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>Uf, oproti Reactímu kódu vidím docela velké rozdíly:
1. Reactí komponenta dostává jen ty parametry, které mu explicitně předáte, zatímco ten kód v include dostane celý scope. I pokud ten includnutý soubor bude využívat jen to, co dostal, může to snadno přitáhnout moji pozornost. Ale snadnost se (třeba při refactoringu) může stát, že omylem využije i něco navíc a kód bude zapletený.
2. Důsledek #1: když zapomenu předat nějaký parametr nebo se uťuknu v názvu, nemusím dostat chybu. Místo toho se tam může předat nějaký parametr z minula.
3. Reactí komponenta neovlivní proměnné tomu, kdo je vkládal, include může. Stačí mít na obou místech stejně pojmenovanou proměnnou…
4. Estetická stránka věci je asi tak to poslední.
Pravda, na tyto problémy není nutně potřeba Reactí komponenta, na to stačí obyčejná funkce.
-
$filter = isset($_GET['filter']) ? $_GET['filter'] : '';
Co když tam někdo předá pole? Když do URL dám filter[]=foo, je tam pole. (BTW, v kombinaci se zapnutým zobrazení chyb je to často snadný způsob, jak trošku analyzovat cizí kód.)
Pokud se tam předá pole, bude tam pole - to nezpůsobí nic, zabráním-li SQL injection pomocí parametrizovaných queries.
Eventuálně pro web pro nějakou firmu který je obnažený do Internetu, by šlo napsat nějakou jednoduchou Util metodu pro získání těch parametrů a validaci.
<td><?= $item['name'] ?></td>
To je učebnicová ukázka HTML injection, a tedy XSS, ne? Frameworky to typicky z velké části řeší, byť třeba u odkazů (kam může přijít třeba javascript:alert(location.href)) si je stále někdy potřeba dát pozor. (I když to asi může řešit CSP.)
Ano, ten kód vede k proveditelnosti HTML injection, správně by se mělo vše vykreslovat přes funkci:
htmlspecialchars($item['name'] )
Nelíbí se mi ale, že to komplikuje template, takže tady by se asi hodil nějaký framework.
<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>Uf, oproti Reactímu kódu vidím docela velké rozdíly:
1. Reactí komponenta dostává jen ty parametry, které mu explicitně předáte, zatímco ten kód v include dostane celý scope. I pokud ten includnutý soubor bude využívat jen to, co dostal, může to snadno přitáhnout moji pozornost. Ale snadnost se (třeba při refactoringu) může stát, že omylem využije i něco navíc a kód bude zapletený.
Ano, je to další nevýhoda toho zápisu. Přesto, na vadné vstupní parametry mě umí částečně upozorní IDE (PHP Storm).
Na závěr bych chtěl říct, že nejsem profi programátor Internetových webů, dělám jen technické Intranetové webovky, a jinak nějaké drobnosti jako koníček. A jednoduchost použití PHP mě docela překvapila - jenom se vezme index.php, hodí se to do "/var/www/html" a je to, mám web.
Ještě o stupínek složitější, ale taky pořád jednoduché, je použít Python s Bottle třeba a k tomu templates.
Např. ani jeden z "jednoduchých" webů, které jsem dělal v Reactu, tak nemá tak dobře vyřešenou navigaci přes uri parametry, jako to udělá defaultně PHP. V Reactu se to musí naprgramovat, aby byla page řízená parametry přítomnými v URI, načež následně fungují dobře tlačítka Zpět a Vpřed v browseru, že.
Co mi ale na těch Server side technologiích trochu vadí je třeba to, že browser neumí uživatele vrátit zpátky na pozici na stránce, kde se nacházel při kliknutí na nějaký Submit. Jako např. že bych měl někde dole na vstupu formulár:
- Zadejte tel. číslo
- Button: Poslat ověřovací sms
Tak bohužel u server side renderingu neudělám to, že by browser nascroloval zpátky na to místo. Leda přes záložky, ale to se nechová idálně.
-
Co mi ale na těch Server side technologiích trochu vadí je třeba to, že browser neumí uživatele vrátit zpátky na pozici na stránce, kde se nacházel při kliknutí na nějaký Submit.
Tak ono by to šlo s javascriptem - ukládat scroll pozici do hidden field v tom formuláři, a pak se na to místo zas posunout.
-
Předně, mě je úplně jasné, že v tomhle jazyce se na webových projektech nachází napsaný totální binec, s mixováním php kódu a template, jak jsem to viděl, kde ještě ke věcmu místo aby autoři kódu v templates používali shorthands, tak tam dávají samé echo.
Většinou ne, běžně se používá MVC pattern (a nějaký framework) který odděluje View od Modelu a Controlleru. Doba kdy se psaly takhle "běžně" skripty je už dávno pryč. Tak nějak od PHP5+
A jednoduchost použití PHP mě docela překvapila - jenom se vezme index.php, hodí se to do "/var/www/html" a je to, mám web.
No, to je právě ten problém kterým trpí PHP. Ono to takhle jde udělat ale nikdo se v tom nevyzná. Teda nikdo kdo programuje nějaký pátek. A úpravy budou porod.
Co mi ale na těch Server side technologiích trochu vadí je třeba to, že browser neumí uživatele vrátit zpátky na pozici na stránce, kde se nacházel při kliknutí na nějaký Submit. Jako např. že bych měl někde dole na vstupu formulár:
Ano, protože to je serverside. A prohlížeč musí načíst celou stránku znovu. Proto ten "reset" (neví že se jedná o tu samou stránku, jen třeba navíc s chybou). Osobně teď jsem třeba začal psát jeden soukromý projekt a už jsem to striktně začal oddělovat. SS jen API, front komplet Vue3 a všeobecně nějaký takový mix mě přijde jako nejlepší jak vytáhnout z obou světů to nejlepší
-
Proc framework?
1) proc pouzivas React ci Vue? Setri to praci.
2) kdyz nepouzijes framework tezko najdes ty (nebo zakaznik) kohokoliv, aby to upravil kdyz ty nebudes moct
3) proc vymyslet kolo?
4) prave s frameworkem omezujes bordel, delas kod prehlednym
5) kdyz pridas veci jako phpstan, phpunit, code standards tak se v ramci dobreho tymu stava PHP plně typovanym jazykem
PHP dnes je jine nez PHP 10 let zpatky (neco by bylo spatne kdyby to bylo stejne).
Decoupled sice prinasi nejakou komplexitu navic, ale zase umoznuje vyuzivat vyhody obou stran.
-
1. Reactí komponenta dostává jen ty parametry, které mu explicitně předáte, zatímco ten kód v include dostane celý scope. I pokud ten includnutý soubor bude využívat jen to, co dostal, může to snadno přitáhnout moji pozornost. Ale snadnost se (třeba při refactoringu) může stát, že omylem využije i něco navíc a kód bude zapletený.
2. Důsledek #1: když zapomenu předat nějaký parametr nebo se uťuknu v názvu, nemusím dostat chybu. Místo toho se tam může předat nějaký parametr z minula.
3. Reactí komponenta neovlivní proměnné tomu, kdo je vkládal, include může. Stačí mít na obou místech stejně pojmenovanou proměnnou…
4. Estetická stránka věci je asi tak to poslední.
Proto v PHP pouzivame napr Twig.
-
Framework je v PHP dobry na to aby priniesol poriadok do PHP, ktory varili ako psicek a macicka (v JS je to rovnake).
A navyse, preco by clovek nechcel super sablonovaci jazyk, ktory bezi na inom sablonovacom jazyku?
-
Framework za teba vyrieši veci, ktoré by si inak musel naprogramovať sám, prípadne sám lepiť dokopy rôzne knižnice. Napr:
- MVC architektúra, adresárová štruktúra projektu, routovanie URL na konkrétnu logiku, friendly URL, šablónovanie a tak
- formuláre, validácia vstupov, error handling
- security, authentication, authorization, RBAC, ochrana proti útokom ako SQL injection, XSS, CSRF...
- datová vrstva, najeký ORM systém, migrácie dát
- REST API, GraphQL API
- ...
Niektoré frameworky toho ponúkajú viac, iné menej (tzv "microframeworks"). Niektoré sú veľmi striktné ohľadom spôsobu ich použitia ("opiniated"), iné ti nechajú viac voľnosti. Stačí si vybrať.
Spomínal si, že poznáš React a Vue. Takže nejaký microframework s REST API a ORM by mohol byť pre teba fajn.
Ak plánuješ riešiť frontend priamo cez PHP bez JS frameworku, vyber si nejaký opiniated framework, ktorý poskytuje úplne všetko. Budeš mať menej priestoru urobiť nevhodné rozhodnutie.
-
Nez zacnes neco lepit tak se podivej na tyto pojmy: composer, PSR.
-
$filter = isset($_GET['filter']) ? $_GET['filter'] : '';
Co když tam někdo předá pole? Když do URL dám filter[]=foo, je tam pole. (BTW, v kombinaci se zapnutým zobrazení chyb je to často snadný způsob, jak trošku analyzovat cizí kód.)
Pokud se tam předá pole, bude tam pole - to nezpůsobí nic, zabráním-li SQL injection pomocí parametrizovaných queries.
Když se tam předá pole, často to způsobí maximálně warning, ale bez dalšího průzkumu těžko říct. Navíc uhlídat to u aplikace z která se vyvíjí, je dost náročné. Proto mi přijde jednodušší to prostě ošetřit a dál se spoléhat na to, že mám požadovaný typ.
Eventuálně pro web pro nějakou firmu který je obnažený do Internetu, by šlo napsat nějakou jednoduchou Util metodu pro získání těch parametrů a validaci.
Útočník může být i uvnitř sítě. Třeba malware na jednom stroji. A pokud uvažujeme o web bez HTTPS, je tam ještě více možností. Třeba pokud se neověřuje hlavička Host, pak DNS rebinding mi z prohlížeče uživatele udělá proxy, kterou se dostanu do vnitřní sítě. Nebo pokud jsou v síti přenosná zařízení, která se připojují leckam, může někdo udělat browser cache poisoning a jeho skript pak následně bude mít přístup k síti. Intranet za mě není důvod, proč se vykašlat na bezpečnost.
Ad util metoda – postupem času se takovéto věci nasbírají a najednou zjistíte, že si píšete vlastní framework…
-
Tak díky za nadstandardně dobré rady, zejména panu Šestákovi, já měl představu, že to bude jednodušší, ale právě mi z toho asi vypadlo, že zůstane u mého komba Python Bottle + Vue.js (bez kompilace) pro moje jednoduché weby - a tohle schované za nějakým Apache nebo Nginx.
Jamile už nemůžu v PHP jednoduše něco udělat (Ty security omezení vyloženě tlačí do frameworku), tak to pro mě asi smysl moc nedává. Akorát teda - komunity, třeba herní nebo jiné, tak oni amatérsky znají PHP a mají rozjeté někdy i svoje hostující servery, takže tam to PHP má smysl, protože Vue a Pythonu by nerozuměli.
No a v práci stejně dělám backend v Javě, takže budu věřit, že vyjma SQL injection nemusím moc co v kombinaci s Vue.js řešit.
-
No a v práci stejně dělám backend v Javě, takže budu věřit, že vyjma SQL injection nemusím moc co v kombinaci s Vue.js řešit.
PHP má oproti Jave tú výhodu, že backend rozbehneš na lacnom hostingu za pár desiatok eur na rok. Naproti tomu, pre Java backend budeš potrebovať aspoň VPS server, a to stojí rádovo 10x viac. Plus potrebuješ byť trochu zbehlý v administrácii vlastného servera. V závislosti od tvojich potrieb to možno zaváži, možno nie :)
Mimochodom, framework pre PHP má zhruba taký istý význam, ako framework pre Javu. Ten backend v práci určite nepíšeš v čistom Java Servlet API, ale používaš niečo ako Spring.
-
Ještě dodám, že ne všechny frameworky řeší všechno z toho, co jsem psal. Ale jsou to věci, se kterými frameworky běžně pomáhají. Podobně některé frameworky pomáhají řešit například CSRF nebo díky vhodným hlavičkám clickjacking.
Ad Java: Záleží. Když to poběží v rámci něčeho jako AWS Lambda (potom to chce rychlý start, ideálně s native-image), pak VPS netřeba.
-
A jednoduchost použití PHP mě docela překvapila - jenom se vezme index.php, hodí se to do "/var/www/html" a je to, mám web.
Zabudli ste spomenúť, že najprv treba nakonfigurovať a nainštalovať webserver. Čo je často tá najťažšia časť. (z rôznych dôvodov, nebudem rozpitvávať)
-
A ještě mi vadí další věc, že v PHP je nějaká kultura abuzu ECHO, viz úryvek z pluginu v DokuWiki:
A presne na tom je krasne videt, jak mizivy zkusenosti mas.
On toti zneni entr jako entr, a ruzny casti retezce (tim myslim od toho phpka k browseru) to muzou ruzne interpretovat.
Michani kodu a html sice odjakziva funguje, ale taky to je odjakziva bezpecnostni megafail. Ono ti totiz z libovolnyho duvodu muze na tom serveru to php chcipnout, a pak ti ten web naserviruje ten kod. A copak tam casto byva napsano? Treba login do databaze ...
-
...
Tážeš se, k čemu v PHP použít framework, a uvádíš příklad Vue a Reactu v javascriptu. Nejsi trochu nekonzistentní?
PHP je jazyk, a s jako takovým si můžeš vystačit. Stejně jako si můžeš vystačit s čistým javascriptem.
Ale obvykle si člověk chce trochu zjednodušit život. A tak si vybere knihovnu nebo framework, který jde jeho směrem. V PHP to bude Nette, nebo Symphony, v javascriptu to bude vue, nebo react. V některých případech to zjednodušit si život klidně může být, že žádný fw nepoužije.
Když zapátráš, tak dokonce proběhla vlna takzvaných microframeworků.
Nebo mě osobně hodně oslovil HTMX a jemu podobné.
-
V PHP to bude Nette, nebo Symphony,
1) je to Symfony a ne Symphony
2) Nette jako onemanshow bych fakt doporucil se vyhnout (bud Symfony nebo Laravel)
Zabudli ste spomenúť, že najprv treba nakonfigurovať a nainštalovať webserver. Čo je často tá najťažšia časť. (z rôznych dôvodov, nebudem rozpitvávať)
Nezabudli protoze nakonfigurovany PHP hosting prodava dneska kazda Maruške z pneuservisu.
-
2) Nette jako onemanshow bych fakt doporucil se vyhnout (bud Symfony nebo Laravel)
Mýtus. A to, že je Laravel dobrý fw druhý. Každopádně, to už je offtopic.
-
Nejspíš zde spustím slušný flamewar, ale z mého pohledu je Nette dlouhodobě mrtvé.
Ten projekt nemá žádnou dlouhodobou ani krátkodobou vizi, nemá žádnou roadmapu. Je jen zakonzervovaný a dělá se jen běžná údržba.
Do repozitářů pushuje jen grudl a velmi zřídka někdo jiný, ale pořád to stojí jen na grudlovi.
Komunita kolem toho už slušně usíná a svou největší slávu to už má za sebou.
Tím ale nechci říct, že je to špatné. Ano, nadávám tam na spoustu věcí, ale u jiných frameworků zase na něco jiného. Jen to prostě proti Symfony stojí na jednom člověku, který když se na to vykašle, tak to chvilku ještě bude fungovat setrvačností a pak už o tom ani pes neštěkne.
-
ve světě linux a open source se používá miliony věcí, které stojí na jediném člověku.
Pro mě je stav, kdy je kód konzervovaný, chyby opravované zase výhoda, nemusím aplikaci co rok přepisovat, aby to fungovalo nebo naopak neaktualizovat.
V práci si užívám dost neustálého přepisování, tak jsem občas rád, když mohu mít doma kód, na který jsem deset let nemusel šáhnout, protože funguje a není potřeba ho opravovat.
-
Nejspíš zde spustím slušný flamewar, ale z mého pohledu je Nette dlouhodobě mrtvé.
Ten projekt nemá žádnou dlouhodobou ani krátkodobou vizi, nemá žádnou roadmapu. Je jen zakonzervovaný a dělá se jen běžná údržba.
Do repozitářů pushuje jen grudl a velmi zřídka někdo jiný, ale pořád to stojí jen na grudlovi.
Komunita kolem toho už slušně usíná a svou největší slávu to už má za sebou.
Toto naštěstí nemohu potvrdit.
Tím ale nechci říct, že je to špatné. Ano, nadávám tam na spoustu věcí, ale u jiných frameworků zase na něco jiného. Jen to prostě proti Symfony stojí na jednom člověku, který když se na to vykašle, tak to chvilku ještě bude fungovat setrvačností a pak už o tom ani pes neštěkne.
Co se týče Nette, vyzdvihnul bych jednu filozofickou odlišnost oproti ostatním (jediná reálná konkurence je Symfony).
Zatímco Symfony používá scaffolding, tak Nette používá code-generation. Samozřejmě každý si vybere podle svého uvážení. Ale vzhledem k tomu, že scaffolding považuji za slepou uličku, tak podle mě má Nette velký potenciál.
Druhá věc je ta, že pokud chcete moderní fw, které navrhují a vyvíjí vývojáři s určitým citem pro správné postupy, tak ono kromě těchto dvou není moc z čeho vybírat. Ostatní fw jsou buď zastaralé, nebo architektonicky chybné, nebo neznámé.
-
synovec je na it stredni skole a zacali s cistym php a k js se dostanou pozdeji, upkne bych ten vyber neschvaloval, ale je to jednodussi.
hledam modul do webserveru, ktery by stejne jako php fungoval treba pro golang i kdyz tady se spis pouziva vsecko v golangu a nginx jako proxy.
a kupodivu php s frameworky je furt ve hledacku zamestnavatelu.
-
Nette v zahraničí nikdo nezná. Asi zaspali s marketingem. Laravel mi přijde jako když někdo, kdo myslí funkcionálně, začne programovat objektově. Že by to bylo nějak krásné mi teda moc nepřijde. Symphony jsem nezkoušel.
-
Nejspíš zde spustím slušný flamewar, ale z mého pohledu je Nette dlouhodobě mrtvé.
Konstatovanim faktu nespustis flamewar. Je to mrtvy, je to jen CZK lokalni zalezitost.
-
a kupodivu php s frameworky je furt ve hledacku zamestnavatelu.
Je to pragmaticka volba, souvisi spis s HR (ne tim oddelenim, ale dostupnosti lidskych zdroju) nez technickou dokonalosti. Na spoustu veci je proste PHP (nebo klidne i ten typescript) dostatecne dobre pri nejake cene nez by se vyplatilo to delat dráž s tim, ze to je mozna "kvalitnejsi" jazyk.
-
Jediné co mi vadí je poněkud obstaróžní práce s fragmenty:
<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>
Takovou hrůzu by mě nenapadlo napsat. Include, resp. require používám výjimečně - obvykle jen jednou v celé aplikaci.
A ještě mi vadí další věc, že v PHP je nějaká kultura abuzu ECHO, viz úryvek z pluginu v DokuWiki:
...
Který by šel přitom napsat jako
echo <<<HTML
<dt>
<span class="datetime">$dt</span>
<span class="log">
<span class="msg">$msg</span>
<span class="file">$file</span>
</span>
</dt>
HTML;
Tohle se jmenuje Heredoc a dříve jsem ho také používal a dosud netuším, co proti němu všichni mají. Teď používám šablony, takže v celé aplikaci mívám jen jedno echo.
-
Ano, ten kód vede k proveditelnosti HTML injection, správně by se mělo vše vykreslovat přes funkci:
htmlspecialchars($item['name'] )
Nelíbí se mi ale, že to komplikuje template, takže tady by se asi hodil nějaký framework.
Proto takové věci dělám mimo template, kde je to jednodušší a přehlednější. Template si tak nemůže převzít jakýkoli údaj, ale pouze data, která mu předám a v předem stanoveném formátu. Ten, který se stará o template, nemusí znát PHP.
-
Jediné co mi vadí je poněkud obstaróžní práce s fragmenty:
<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>
Takovou hrůzu by mě nenapadlo napsat. Include, resp. require používám výjimečně - obvykle jen jednou v celé aplikaci.
Jak teda bez frameworku použiješ v HTML kódu fragment?
-
Chatgpt vytrvale rika, ze pro reusable components se to dela v PHP takto:
// components/Button.php
function Button($text, $href) {
return "<a href=\"" . htmlspecialchars($href) . "\">$text</a>";
}
A potom:
$html = Button('OK', '/submit');
echo $html;
A to je takový piece of crap, že bych raději udělal:
<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>
Ačkoliv lepší je si udělat funkci a zavolat jen:
<?php render('nav-button', text = 'Ahoj světe', href = 'page2.php') ?>
Fakt, že Chatgpt v jednom kuse říká takové věci k otázkám k PHP, a výše uvedené nedá nikdy dohromady, v kombinaci s tím, že se dívám do zdrojáků Dokuwiki a vidím:
protected function showMenuItem($item)
{
global $ID;
if (blank($item['prompt'])) return;
echo '<li><div class="li">';
echo '<a href="' . wl($ID, 'do=admin&page=' . $item['plugin']) . '">';
echo '<span class="icon">';
echo inlineSVG($item['icon']);
echo '</span>';
echo '<span class="prompt">';
echo $item['prompt'];
echo '</span>';
echo '</a>';
echo '</div></li>';
}
Mi indikuje, že v PHP se psaly zjevně strašné crappy. Je jen pár základních konstrukcí, co má umět template:
1. If else
2. Foreach
3. A jak se pracuje s fragmenty (reusable components)
Jsou to jen tyhle výše uvedené 3 základy, a pro tu poslední nemá PHP řešení. No, dá se udělat ta funkce viz výše, ale zjevně to historicky v praxi nikdo nedělal. A z Chatgpt to taky nejde vymáčknout.
-
Jediné co mi vadí je poněkud obstaróžní práce s fragmenty:
<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>
Takovou hrůzu by mě nenapadlo napsat. Include, resp. require používám výjimečně - obvykle jen jednou v celé aplikaci.
Jak teda bez frameworku použiješ v HTML kódu fragment?
Co máš na mysli tím fragmentem? Vše potřebné pro HTML mám v šabloně, do které sypu data. Podle struktury dat se dynamicky vytváří i fragmenty HTML.
-
Chatgpt vytrvale rika, ze pro reusable components se to dela v PHP takto:
:
ChatGPT generuje hezky, ale občas je nutné mu jeho výplody omlátit o čipy.
Fakt, že Chatgpt v jednom kuse říká takové věci k otázkám k PHP, a výše uvedené nedá nikdy dohromady, v kombinaci s tím, že se dívám do zdrojáků Dokuwiki a vidím:
:
global $ID;
:
Mi indikuje, že v PHP se psaly zjevně strašné crappy. Je jen pár základních konstrukcí, co má umět template:
Když vidím global nebo statické třídy, tak začnu vidět rudě.
To je vydolováno ze starých a neudržovaných aplikací. Projdi si raději GitHub.
1. If else
2. Foreach
3. A jak se pracuje s fragmenty (reusable components)
Jsou to jen tyhle výše uvedené 3 základy, a pro tu poslední nemá PHP řešení. No, dá se udělat ta funkce viz výše, ale zjevně to historicky v praxi nikdo nedělal. A z Chatgpt to taky nejde vymáčknout.
V šablonách obvykle používám jen if a i tomu se snažím vyhnout podmíněnými šablonami, které se aktivují jen když poskytnu příslušná data. Snad přijdu na to, co máš na mysli těmi fragmenty.
-
Je jen pár základních konstrukcí, co má umět template:
1. If else
2. Foreach
3. A jak se pracuje s fragmenty (reusable components)
Jsou to jen tyhle výše uvedené 3 základy, a pro tu poslední nemá PHP řešení.
Ještě se taky hodí, když má escaping by default. Což PHP taky nemá.
-
Je jen pár základních konstrukcí, co má umět template:
1. If else
2. Foreach
3. A jak se pracuje s fragmenty (reusable components)
Jsou to jen tyhle výše uvedené 3 základy, a pro tu poslední nemá PHP řešení.
Ještě se taky hodí, když má escaping by default. Což PHP taky nemá.
Což třeba Latte, jako jeden z mála, má.
-
Chatgpt vytrvale rika, ze pro reusable components se to dela v PHP takto:
// components/Button.php
function Button($text, $href) {
return "<a href=\"" . htmlspecialchars($href) . "\">$text</a>";
}
to bys neměl takhle dělat, framework má smysl, protože php je plné pastí. Když bude v href třeba tohle
javascript:alert(document.cookie)
tak ti to bez problémů projde a asi nemusím zmiňovat, že alert je jen ukázka, on tam může být skoro jakýkoliv JS kód a ten nepotřebuje uvozovky.
Spousty zábavy si pak zažiješ, když htmlspecialchars použiješ v jiném kontextu nebo na vstupu neošetříš multibyte znaky.
-
Chatgpt vytrvale rika, ze pro reusable components se to dela v PHP takto:
// components/Button.php
function Button($text, $href) {
return "<a href=\"" . htmlspecialchars($href) . "\">$text</a>";
}
to bys neměl takhle dělat, framework má smysl, protože php je plné pastí. Když bude v href třeba tohle
javascript:alert(document.cookie)
tak ti to bez problémů projde a asi nemusím zmiňovat, že alert je jen ukázka, on tam může být skoro jakýkoliv JS kód a ten nepotřebuje uvozovky.
Spousty zábavy si pak zažiješ, když htmlspecialchars použiješ v jiném kontextu nebo na vstupu neošetříš multibyte znaky.
Poznámka: toto není o PHP, a o tom, že by PHP bylo plné pastí. Ostatně ať si tazatel zkusí to samé v javascriptu, nebo pythonu - vznikne mu tam úplně stejná chyba a úplně stejně se to řeší.
Když budu generovat html musím řešit bezpečnost (XSS, HTML Injection, Template Inejection, JS Injection, Clickjacking, etc)
Když budu generovat pdf, musím řešit bezpečnost (* Injection, LFI)
Když budu generovat obrázky, musím řešit bezpečnost (RCE, LFI, EXIF attack)
-
Chatgpt vytrvale rika, ze pro reusable components se to dela v PHP takto:
// components/Button.php
function Button($text, $href) {
return "<a href=\"" . htmlspecialchars($href) . "\">$text</a>";
}
to bys neměl takhle dělat, framework má smysl, protože php je plné pastí. Když bude v href třeba tohle
javascript:alert(document.cookie)
tak ti to bez problémů projde a asi nemusím zmiňovat, že alert je jen ukázka, on tam může být skoro jakýkoliv JS kód a ten nepotřebuje uvozovky.
Spousty zábavy si pak zažiješ, když htmlspecialchars použiješ v jiném kontextu nebo na vstupu neošetříš multibyte znaky.
Kromě htmlspecialchars() existují v PHP i jiné způsoby, jak ošetřit vstup i výstup. Frameworky k tomu opravdu nejsou potřebné a bohužel často dávají tvůrci falešnou představu, že bude vše zabezpečeno.