PHP triky

Weblog o elegantním programování v PHP pro mírně pokročilé

V čem je PHP navrženo lépe než Java

Existuje spousta článků, které kritizují návrh PHP, nejznámější je asi PHP: a fractal of bad design. Na ten jsem napsal jen poměrně krátkou reakci, protože se zbytkem článku v zásadě souhlasím. PHP je skutečně v mnoha ohledech špatně navržený jazyk. V čem je ale navržený lépe než Java?

Článek vyšel na serveru Zdroják.

Jakub Vrána, Seznámení s oblastí, 4.7.2014, diskuse: 1 (nové: 1)

Rekurze regulárních výrazů

Když někdo říká, že umí dobře regulární výrazy, tak mu obvykle položím tuto otázku: „Jaký je rozdíl mezi once-only subpattern a possessive quantifier a kdy je použiješ?“ Schválně si na tuhle otázku teď zkuste odpovědět.

Once-only subpattern (?>) se vyznačuje tím, že zkonzumuje, co se dá, a nikdy se nevrací. Pokud tedy za zkonzumovanou částí nenajde text odpovídající zbytku regulárního výrazu, tak skončí chybou. Jindy se v takových situacích pokusí regulární stroj vrátit a hledat shodu dřív.

Possessive quantifier se zapisuje jako plus za kvantifikátorem, např. *+. Tento výraz je velmi podobný – sežere, co jde, a nikdy se nevrací. Jediný rozdíl je tedy v tom, že possessive quantifier je trochu stručnější, pokud chceme vyjádřit opakování. a*+ se dá zapsat jako (?>a*). Naopak to jde taky, i když trochu krkolomněji – (?>ab) se dá zapsat jako (?:ab){1}+. Odpověď na první část otázky tedy je, že rozdíl mezi těmito výrazy není žádný a používají se ve stejných situacích.

Používají se tehdy, když potřebujeme zabránit rekurzi, kterou regulární stroj používá při hledání shody. Na její limit (pcre.recursion_limit) můžeme narazit především při použití opakování uvnitř opakování, např. (\d+,)*.

Alternativou k regulárním strojům používajícím rekurzi nabízí knihovna RE2, která zaručuje běh v lineárním čase. Je trochu omezenější než Perlové regulární výrazy, např. nepodporuje lookahead aserce. Existuje i verze pro PHP, nicméně kvůli její nedostatečné rozšířenosti ji nepoužívám.

Jakub Vrána, Seznámení s oblastí, 25.6.2014, diskuse: 1 (nové: 1)

Adminer 4.1.0

Asi největší novinkou právě vydané verze Admineru je ochrana proti pokusu o získání hesla k databázi hrubou silou. Adminer nově dovolí jen 30 neplatných pokusů o přihlášení za 30 minut (počítáno od prvního neplatného pokusu). Další pokusy (ať už se správným nebo špatným heslem) se ignorují, dokud nevyprší časový limit. Limit se vztahuje na IP adresu, nikoliv na uživatelské jméno. To je ze dvou důvodů:

  1. Útočník může zkoušet různá uživatelská jména, nemusí být zaměřen jen na jedno.
  2. Při vazbě na uživatelské jméno by útočník mohl oprávněnému uživateli zabránit v přihlášení úmyslným zadáváním špatných hesel (DoS).

Limit je poměrně velkorysý, protože mě rozčiluje, když mi některé služby třeba po třech neplatných pokusech o přihlášení ukážou dlouhý nos. Také jsem zohlednil, že stejnou IP adresu může používat více uživatelů, např. ze stejné firmy s proxy serverem. Pokud máte webový server umístěný za reverzní proxy a všechny požadavky chodí ze stejné IP adresy, tak je vhodné implementovat metodu Adminer::bruteForceKey() tak, aby vracela poslední část hlavičky X-Forwarded-For. Jinak vám hrozí DoS. Hlavička X-Forwarded-For se bohužel nemůže kontrolovat automaticky, protože jde triviálně podstrčit.

Přemýšlel jsem i o přidání CAPTCHA, což by zamezilo riziku DoS. reCAPTCHA ale používá privátní klíč, který by musel být součástí Admineru, a ostatní řešení jsou obvykle celkem snadno prolomitelná.

Data se ukládají do upload_tmp_dir nebo pokud není nastaven, tak do sys_get_temp_dir(). Tyto adresáře někdo pravidelně promazává, nicméně vzhledem k poměrně krátké platnosti dat by to nemělo moc vadit.

I přes tuto ochranu je vhodné přístup k Admineru omezit, např. v Apache pomocí Access Control. Případně pokud Adminer použijete někde jen jednorázově, tak ho zase po sobě smažte. Odkaz na Adminer také nikam zbytečně nedávajte a neumisťujte ho na snadno uhodnutelnou adresu. Pokud Adminer používají zákazníci vašeho hostingu, tak jim k němu umožněte přístup jen pokud jsou přihlášeni do administrace hostingu.

Další novinky

Jakub Vrána, Adminer, 18.4.2014, diskuse: 24 (nové: 24)

Přechod na SafeHtml

Ve většině moderních aplikací vzniká HTML kód převážně v šablonách. To má nespornou výhodu v tom, že ošetřování dat stačí vyřešit na jednom místě. Můžeme použít automatické escapování, kontextově citlivé escapování, můžeme úplně zakázat vypsat text bez jeho ošetření. I v těchto aplikacích může být ale šikovné si tu a tam vygenerovat HTML kód, který do šablony pošleme. Můžeme totiž využít plnou sílu programovacího jazyka – metoda může vracet HTML kód a potomek ji může přetížit a vrátit něco jiného. Samozřejmě si tyto metody vevnitř můžou také zavolat šablonu, ale jednak někdy šablonovací systém nemají po ruce a jednak to je trochu jako kanón na vrabce, když chtějí vrátit třeba jenom <em>text</em>.

Facebook

Facebook žádné šablony nepoužívá a když nějaká část programu chce vytvořit HTML, tak to udělá pomocí XHP. Vede to k trochu odlišnému způsobu programování – místo velké aplikace, která generuje datové struktury, a velkých šablon, které tyto struktury zpracovávají a které jsou od hlavního kódu obvykle poměrně daleko, je všechno pěkně pohromadě. XHP je obvykle malé a jednoduché, protože vytváří jen malou část výsledku s využitím dalších komponent, které taky vytváří XHP. Všechny výhody šablon týkající se ošetřování dat jsou přitom díky XHP zachovány.

Phabricator

Phabricator vznikl ve Facebooku a je napsán do značné míry podobně. Nepoužívá žádné šablony, HTML kód se vytváří lokálně s využitím síly programovacího jazyka. Problém je, že nemá k dispozici XHP, takže HTML kód se vracel jako ručně ošetřované řetězce. Vzhledem k tomu, že kód vytváří velmi zkušení programátoři a všechny změny prochází code review, tak v historii nedošlo k mnoha případům nedostatečného nebo nadbytečného ošetřování. S kódem se ale pracovalo poměrně nepohodlně především proto, že nebylo jasné, co vrací nebo přijímá správně ošetřený HTML kód a co vrací nebo přijímá čistý text, který je nutno ošetřit.

Navrhl a realizoval jsem proto změnu, po které se všechny řetězce považují za čistý text a pokud něco chce vytvořit ošetřený HTML kód, tak musí vrátit PhutilSafeHtml. Vtip je v tom, že tento objekt si nemůže vytvořit jen tak někdo, ale musí k tomu použít jednu ze dvou funkcí. Buď phutil_tag, která přijímá název značky, pole atributů a obsah, nebo hsprintf, která přijímá formátovací řetězec a libovolný počet hodnot, které se před dosazením ošetří. Obsah může být buď řetězec, který se automaticky ošetří, nebo PhutilSafeHtml, kterému se věří. hsprintf v prvním parametru přijímá jen konstantní řetězec, za což ručí lint rule.

Při pohledu zpět se funkce hsprintf ukázala jako zbytečná – někdy je sice jednodušší ji použít, ale zbytečně zmírňuje silné záruky, které dává funkce phutil_tag. Ta dovoluje vytvořit jen správně spárované HTML značky, navíc může kontrolovat např. i hodnotu atributu <a href="">, aby nezačínala třeba javascript:. hsprintf nic z toho dost dobře dělat nemůže. Úplně by stačila funkce vytvářející značku a funkce spojující kombinaci neošetřených řetězců a PhutilSafeHtml do jednoho PhutilSafeHtml. A možná ani ta ne, protože funkce jako obsah přijímá i pole hodnot, které zřetězí.

Když odhlédnu od množství nudné práce, kdy bylo potřeba všechny řetězce vytvářející HTML kód převést na jednu z těchto dvou funkcí, tak byla změna vlastně docela jednoduchá. Pokud někdo konzumoval čistý text a dostal PhutilSafeHtml, tak se zavolala jeho metoda __toString. Maximálně hrozilo, že pokud tento text poslal dál, tak se při příštím použití znovu ošetřil. Tyto případy se nám podařilo celkem rychle vychytat. Pokud někdo začal konzumovat PhutilSafeHtml a dostal řetězec, tak ho prostě poslal dál – všechny funkce považují řetězec za platný vstup, který se na PhutilSafeHtml ve finále převede jeho ošetřením. Díky tomu není potřeba nikde v kódu ručně ošetřovat jakákoliv data.

Proč mi změna přišla vlastně docela jednoduchá, i když se týkala desítek tisíc řádek kódu? Hlavní důvod je ten, že celý kód máme pod kontrolou – pokud se rozhodneme změnit API nějaké metody, tak můžeme změnit i všechna její volání.

Closure Library

Obdobnou změnu nyní pomáhám realizovat i pro Closure Library. Closure Tools sice obsahuje vynikající šablony Closure Templates (alias Soy), knihovna na nich ale nezávisí, takže je nemůže používat.

Snažíme se odstranit všechna místa, která přiřazují řetězec do innerHTML, a nahradit je voláním funkce, která přijímá SafeHtml. Pokud budete chtít SafeHtml vytvořit z uživatelského vstupu, tak k tomu můžete použít funkci SafeHtml.from, která pro vás data ošetří. Pro vytvoření něčeho složitějšího jsem původně navrhl takovéto API:

var html = new SafeHtmlBuilder(TagName.A)
	.setAttribute('href', href)
	.addContent(text)
	.addContent(new SafeHtmlBuilder(TagName.BR).build())
	.build();

Byl to moc velký Javismus, takže jsme nakonec skončili u něčeho podobného jako ve Phabricatoru: SafeHtml.create('a', {'href': href}, [text, SafeHtml.create('br')]). Kromě toho vznikla ještě funkce SafeHtml.concat umožňující spojit více SafeHtml do jednoho.

Převod stávajícího API tak jednoduchý jako ve Phabricatoru bohužel nebude. Vezměme si třeba metodu goog.ui.tree.BaseNode#getHtml. Ta může být jak přetížená, tak ji může kdokoliv volat. Nemůžeme ji tedy změnit tak, aby prostě začala vracet SafeHtml, protože bychom všechny rozbili a navíc by naši potomci SafeHtml stejně nevraceli. Zvolili jsme tedy takovéto, poněkud krkolomné řešení:

Závěr

Zápis HTML jako řetězce sice napomohl jeho masivnímu rozšíření, ale ještě dnes přináší problémy i ve velkých společnostech. Pokud někde ve svém kódu uvidíte něco jako return "<br/>", tak je nejspíš vaše infrastruktura špatně a vyplatí se investovat energii do toho ji co nejdříve změnit. Čím později to uděláte, tím to bude bolestivější.

Jakub Vrána, Řešení problému, 11.3.2014, diskuse: 5 (nové: 5)

Adminer 4.0.0

Hlavní novinkou právě vydané verze Admineru jsou ovladače pro NoSQL databáze. Konkrétně SimpleDB, MongoDB a Elasticsearch. Poslední dva jsou nedodělané a jsou označené jako beta, i tak jsem se je ale rozhodl zveřejnit – hlavně pro případ, že by je někdo chtěl dokončit. Sám MongoDB a Elasticsearch momentálně nepoužívám, tak k tomu mám malou motivaci.

Dalších novinek je také požehnaně:

Opravil jsem také několik chyb zavlečených v předchozích verzích:

Několik vylepšení se týká také bezpečnosti:

Některé novinky jsou k dispozici jen v některých ovladačích:

Přibyla portugalština používaná v Portugalsku a thajština.

Jakub Vrána, Adminer, 7.1.2014, diskuse: 82 (nové: 82)

Starší články naleznete v archivu.

avatar © 2005-2014 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.