Hurá, Nette už má první záznam v CVE! To znamená, že
v něm byla objevena první vážná zranitelnost. Co se vlastně stalo?
Na konci prázdnin mi napsal vývojář Cyku
Hong z malebného Taiwanu, že našel v Nette zranitelnost a
v následujícím e-mailu vysvětlil princip možného zneužití. Ověřil
jsem, že jde o uskutečnitelný útok. Dovoluje útočníkovi za určitých
okolností na některých webech pomocí speciálně sestaveného URL spustit
kód, tedy jde o zranitelnost Remote code execution (RCE). Cyku, díky!
Musím říct, že to bylo v 13leté historii frameworku Nette vlastně
poprvé, co někdo našel takto závažnou zranitelnost. Dříve byly
několikrát reportovány drobné záležitosti, např. letos v březnu Jan
Gocník odhalil možnou zranitelnost v případě, že by programátor
deserializoval a vypsal query proměnnou
echo unserialize($_GET['a']), což je samo o sobě principiálně
velmi nebezpečné, nicméně jeho nález jsem samozřejmě opravil. Také jsem
dostal řadu hlášení, které nebyly opodstatněné, například že
uploadovaný obrázek vyhovující testu isImage() může v sobě
obsahovat PHP kód. Což samozřejmě může, například v metadatech, ale
není to bezpečnostní problém Nette.
Ale zpět k chybě, o které je tento článek. Bezprostředně po
nahlášení jsem ji opravil a vydal nové verze balíčků
nette/application a nette/nette.
Nejstarší zasaženou verzí bylo Nette 2.0, které už sice není 6 let
udržované, ale protože Nette má bezpečnost jako jednu z priorit, vydal
jsem nové verze také u všech nepodporovaných verzí. Což je ve světě
opensource frameworků ojedinělý krok. Díky tomu mohou uživatelé snadno
a bez prodlení aktualizovat nejen projekty udržované a běžící na
současných verzích, ale i projekty s technologickým dluhem. Vlastně
se teď dá říci, že každá řada Nette je nejen Long-Term Support
Release (tedy podporovaná alespoň dva roky, viz tabulka), ale z pohledu
bezpečnostních fixů i Forever-Term Supported ?
Druhým krokem bylo o chybě informovat. Samotné zveřejnění chyby na
blogu by i bez podrobného popisu zneužití představovalo vodítko pro
darebáky, kteří by se o chybě dozvěděli a mohli se pokusit ji zneužít.
Proto mi připadalo fér nejprve informovat všechny podporovatele Nette, poté i další
uživatele na které mám kontakt a teprve s určitým časovým odstupem
publikovat oznámení veřejně na blogu,
GitHubu
a katalogu
CVE. Prostě dát partnerům určitý čas zaktualizovat všechny weby
dříve, než by se objevil první útočník. Původně jsem zamýšlel dát
odstup týden, ale pak jsem na základě diskusí pochopil, že to je doslova
šibeniční termín a vhodnější je dát alespoň 2–4 týdny.
Jak už jsem zmiňoval, šlo o mou první zkušenost s takovou situací,
ale chtěl jsem ji zvládnout příkladně. Abych se nedopustil žádného
přešlapu, napsat jsem Michalu
Špačkovi, kterého považuji za nejlepšího odborníka v této oblasti,
a všechno s ním konzultoval. Michal mi schválil postup, dal řadu
užitečných rad, připomínkoval emaily atd. Michale, moc děkuji!
Ačkoliv žádný z mnou provozovaných webů nebyl tímto způsobem
zranitelný, prohledal jsem jejich access logy za posledních 8 let (co díra
existuje) a zjistil, že tento typ útoku na ně historicky nikdo nezkusil.
Soudím, že na zranitelnost nikdo dříve nepřišel. Útočníci totiž
obvykle zkouší testovat také přímo web nette.org.
Nechci zveřejňovat přesný postup zneužití chyby a doufám, že to ani
nikdo jiný neudělá. Alespoň ne v dohledné době, protože by tím
způsobil ostatním nepříjemnosti a zpronevěřil se duchu open source.
Aktualizujte prosím co nejdříve na nejnovější
setinkové verze:
- nette/application 3.0.6 (případně 3.0.2.1, 3.1.0-RC2 nebo dev)
- nette/application 2.4.16
- nette/application 2.3.14
- nette/application 2.2.10
- nette/nette 2.1.13
- nette/nette 2.0.19
Nejrychlejší oprava
Michal připravil Linuxový
skript a já obdobu
v PHP, který automaticky aplikuje patch přímo do zdrojových kódů
Nette na disku. Hodí se v případě, že udržujete velké množství
projektů, které nemáte čas korektně aktualizovat pomocí Composeru.
Informaci o chybě rozeslal emailem svým klientům VSHosting, WEDOS nebo
HostingBB, zároveň některé hostingy přímo blogují problematickou URL,
případně rovnou aplikovaly výše uvedený fix. Díky!!!
SameSite cookies poskytují mechanismus, jak rozpoznat, co
vedlo k načtení stránky. Jestli to bylo prokliknutí odkazu na jiném webu,
odeslání formuláře, načtení uvnitř iframe, pomocí JavaScriptu atd.
Rozlišit, jak byla stránka načtena, je totiž naprosto zásadní kvůli
bezpečnosti. Závažná zranitelnost Cross-Site
Request Forgery (CSRF) je tu s námi už dlouhých dvacet let a teprve
SameSite cookie nabízí systémovou cestu, jak ji řešit.
Útok CSRF spočívá v tom, že útočník naláká oběť na stránku,
která nenápadně v prohlížeči oběti vykoná požadavek na webovou
aplikaci, na které je oběť přihlášena, a ta se domnívá, že požadavek
vykonala oběť o své vůli. A tak pod identitou oběti provede nějaký
úkon, aniž by ta o tom věděla. Může jít o změnu nebo smazání dat,
odeslání zprávy atd. Aby aplikace útoku zabránila, musí rozlišit, jestli
požadavek vznikl povolenou cestou, např. odesláním formuláře v ní
samotné, nebo nějak jinak. SameSite cookie tohle umí.
Jak to funguje? Řekněme, že mám web běžící na nějaké doméně a
vytvořím na něm tři různé cookies s atributy SameSite=Lax,
SameSite=Strict a SameSite=None. Název ani hodnota
nehrají roli. Prohlížeč si je uloží.
- Když libovolnou URL na mém webu otevřu přímým zadáním do adresního
řádku nebo kliknutím na záložku, prohlížeč všechny tři cookie
odešle.
- Když se na libovolnou URL na mém webu dostanu jakkoliv ze stránky
z téhož webu, prohlížeč všechny tři cookie odešle.
- Když se na libovolnou URL na mém webu dostanu ze stránky z jiného
webu, prohlížeč pošle jen cookie s atributem
None a
v určitých případech i Lax, viz tabulka:
| Kód na jiném webu |
|
Odeslané cookie |
| Link |
<a href="…"> |
None + Lax |
| Form GET |
<form method="GET" action="…"> |
None + Lax |
| Form POST |
<form method="POST" action="…"> |
None |
| iframe |
<iframe src="…"> |
None |
| AJAX |
$.get('…'), fetch('…') |
None |
| Image |
<img src="…"> |
None |
| Prefetch |
<link rel="prefetch" href="…"> |
None |
| … |
|
None |
SameSite cookies dokáží rozlišit jen několik málo případů, ale jde
právě o ty podstatné pro ochranu před CSRF.
Pokud mám třeba na webu v administraci formulář nebo nějaký odkaz pro
smazání položky a ten byl odeslán/odkliknut, tak nepřítomnost cookie
vytvořené s atributem Strict znamená, že se tak nestalo na
mém webu, ale že požadavek přišel odjinud, tedy že jde o CSRF útok.
Cookie pro odhalení CSRF útoku vytvářejte jako tzv. session cookie bez
atributu Expires, platnost je pak v podstatě nekonečná.
Doména vs site
„Na mém webu“ není to stejné jako „na mé doméně“, nejde
o doménu, ale o web site (proto i název SameSite). Site sice často
odpovídá doméně, ale třeba u služby github.io odpovídá
subdoméně. Požadavek z doc.nette.org na
files.nette.org je same-site, zatímco požadavek z
nette.github.io na tracy.github.io je už cross-site.
Tady je to hezky
vysvětlené.
<iframe>
Z předchozích řádků již vyplynulo, že pokud je stránka z mého webu
načtená uvnitř <iframe> na jiném webu, nepošle jí
prohlížeč Strict ani Lax cookies. Je tu ale ještě
jedna důležitá věc: pokud takto načtená stránka vytvoří
Strict nebo Lax cookie, prohlížeč je
ignoruje.
Tím vzniká možnost se bránit proti podvodnému získávání cookie
neboli Cookie
Stuffing, kde dosud systémová obrana taky chyběla. Trik spočívá
v tom, že podvodník inkasuje provizi za affiliate marketing, ačkoliv
uživatele na web obchodníka nepřivedl. Místo odkazu s affiliate ID, na
který by musel uživatel kliknout, vloží do stránky neviditelný
<iframe> se stejným odkazem a značkuje tak všechny
návštěvníky.
Cookie bez atributu SameSite
Sušenky bez atributu SameSite se vždy posílaly při jakémkoliv same-site
i cross-site požadavku. Stejně jako SameSite=None. Jenže
v blízké budoucnosti začnou prohlížeče považovat příznak
SameSite=Lax za výchozí, takže sušenky bez atributu budou
považovány za Lax. Což je docela nebývale velký BC break
v chování prohlížečů. Pokud chcete, aby se cookie i nadále chovala
stejně a přenášela se při jakémkoliv cross-site požadavku, je potřeba
jí nastavit SameSite=None. (Pokud nevyvíjíte embedované widgety
apod., moc často to nechcete.) Bohužel pro loňské prohlížeče je hodnota
None nečekaná. Safari 12 ji chápe jako Strict,
takže na starších iOS a macOS vzniká ošemetný problém.
A ještě pozor: None funguje jen když je nastaven
s atributem Secure.
Co udělat při útoku?
Utéct! Základní pravidlo sebeobrany, jak v reálném životě, tak na
webu. Obrovskou chybou spousty frameworků je, že při detekci CSRF útoku
zobrazí formulář znovu a napíší něco jako „Token CSRF je neplatný.
Zkuste prosím formulář znovu odeslat“. Tím, že jej uživatel odešle
znovu, je útok dokonán. Taková ochrana postrádá smysl, když vlastně
uživatele vyzvete, aby ji obešel.
Ještě nedávno dělal Chrome v případě cross-site požadavku to, že po
refreshi stránku zobrazil znovu, ale tentokrát cookie s atributem
Strict poslal. Takže refresh vyřadil ochranu před CSRF
založenou na SameSite cookie. Dnes už to naštěstí nedělá, ale je možné,
že to dělají jiné nebo starší prohlížeče. Uživatel také může
stránku „refreshnout“ kliknutím na adresní řádek + enter, což se bere
jako přímé zadání URL (bod 1) a všechny cookie se odešlou.
Takže při detekci CSRF je nejlepší přesměrovat s HTTP kódem
302 jinam, třeba na homepage. Zbavíte se tak nebezpečných POST dat a ani
problematická URL se neuloží do historie.
Nekompatibility
SameSite dlouho nefungovalo ani zdaleka tak, jak by mělo. Především
kvůli chybám v prohlížečích a nedostatkům ve specifikaci, která třeba
vůbec neřešila přesměrování nebo refresh. Samesite cookie se
nepřenášely třeba při uložení nebo tisku stránky, naopak se přenášely
po refreshi, když zrovna neměly atd. Naštěstí dnes už je situace lepší.
Mám za to, že z vážných nedostatků přetrvává v aktuálních verzích
prohlížečů jen ten výše zmíněný u Safari.
Doplnění: kromě SameSite lze velmi čerstvě rozlišit původ
požadavku i hlavičkou Origin,
což je nástupce hlavičky Referer více respektující soukromí uživatelů a
pravopis.
Abych si přiblížil vývoj na lokálním počítači tomu
ostrému, zprovoznil jsem si lokální https. Jak na to?
Nejsnazší cesta
V komentářích padla zmínka o aplikaci mkcert, která následující
postup udělá za vás. Ale pokud máte rádi ruční práci, čtěte
dál :)
Vygenerujeme SSL certifikát
K tomu použijeme program openssl, který určitě na
počítači najdete, třeba jako součást Gitu na
C:\Program Files\Git\usr\bin\openssl.exe nebo jinde. Následující
příkaz vygeneruje klíč do souboru rootCA.key. Bude to po vás
chtít vymyslet nějaké heslo, které si uložte.
openssl genrsa -des3 -out rootCA.key 2048
Další příkaz z klíče vygeneruje kořenový SSL certifikát a uloží
ho do souboru rootCA.pem. Jeho platnost bude 2000 dní (tedy pět
let), ale číslo klidně změňte:
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 2000 -out rootCA.pem
Uvěříme certifikátu
Teď oznámíme operačnímu systému, aby certifikát považoval za
důvěryhodný. Postup pro Mac jsem našel třeba
tady, pro Windows je pěkně obrázek za obrázkem sepsaný
zde a pro české Windows jsem vám jej přeložil:
- spustit mmc
- v menu Soubor > Přidat nebo odebrat moduly snap-in
- doubleclick na Certifikáty v levém okně
- zvolte Účet počítače a Další
- ponechte Místní počítač a Dokončit
- zavřete okno tlačítkem OK
- v levém okně zvolte Certifikáty, v pravém Důvěryhodné kořenové
certifikační autority
- pravé tlačítko a v kontextovém menu Všechny úkoly >
Importovat
- objeví se Průvodce importem certifikátu, dejte Další
- vyberte soubor
rootCA.pem a odklikejte průvodce na konec
Ufff, jsme v půlce. Pokračujeme v Konzoli:
- opět v menu Soubor > Přidat nebo odebrat moduly snap-in
- doubleclick na Editor objektů zásad skupiny
- stiskněte Dokončit a zavřete okno tlačítkem OK
- v levém okně otevřete Místní počítač – zásady > Konfigurace
počítače > Nastavení systému Windows > Nastavení zabezpečení >
Zásady veřejných klíčů
- doubleclick na Nastavení ověření cesty certifikátů
- zatrhněte Definovat tato nastavení, Povolit ověřování certifikátů
… a Povolit uživatelům důvěřovat certifikátum …
- potvrďte tlačítkem OK
Hotovo, zavřete Konzoli.
Všichni už certifikátu věří, akorát Firefox chce ještě
popostrčit:
- ve Firefoxu otevřete stránku
about:config
- odklikejte všechna varování
- vyhledejte položku
security.enterprise_roots.enabled
- doubleklikem změňte hodnotu na true
- zavřete stránku
Vyrobíme certifikát pro
webový server
Klikačku máme za sebou, teď vyrobíme certifikáty pro server. Vytvoříme
soubor server.csr.cnf s tímto obsahem:
[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[dn]
C = CZ
ST = Random
L = Random
O = Random
OU = Random
emailAddress = example@example.com
CN = localhost
A dále soubor v3.ext, kde bude uveden seznam všech domén,
které na localhostu provozujete:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = texy.l
DNS.3 = *.texy.l
DNS.4 = nette.l
DNS.5 = *.nette.l
DNS.6 = navlnachekg.l
Jak vidíte, lokální verze webů provozuji na doménách, které končí na
.l, u vás to třeba bude jinak. Ty jednotlivé klíče
DNS.1 apod. je potřeba fakt jako idiot postupně očíslovat.
Následujícím krokem vygenerujeme soubory server.key
aserver.csr:
openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key -config server.csr.cnf
A konečně vygenerujeme SSL certifikát pro server do
server.crt (teď to bude po vás chtít zadat heslo, které jste si
vymysleli na začátku):
openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out server.crt -days 500 -sha256 -extfile v3.ext
Všechny dosud vytvořené soubory včetně hesla si někam uložte. Ať se
totiž změní domény, které provozujete lokálně, jen upravíte
v3.ext a posledním příkazem znovu vygenerujete certifikát pro
server.
Konfigurace webového serveru
Zbývá povolit https na serveru. Tj. nakonfigurovat server tak, aby
naslouchal na portu 443, na kterém běží https, a používal vygenerovaný
certifikát.
Používám Apache, do jehož konfiguračního soubor httpd.conf
jsem přidal následující řádky s cestou k souborům
server.key aserver.crt:
Listen 443
SSLCertificateFile "C:\Apache24\ssl\server.crt"
SSLCertificateKeyFile "C:\Apache24\ssl\server.key"
Konfiguraci virtuál hostů možná řešíte úplně jinak než já, těžko
říct, ale v mém případě zprovoznění obnášelo ke každému virtuálu
jako je
<VirtualHost *>
ServerName localhost
DocumentRoot "W:/"
</VirtualHost>
doplnit ještě druhý:
<VirtualHost *:443>
ServerName localhost
DocumentRoot "W:/"
SSLEngine on
</VirtualHost>
V nginx by mělo stačit do konfiguračního souboru nginx.conf
doplnit pro každý server něco takového:
server {
listen 443 ssl;
ssl_certificate path/to/server.crt;
ssl_certificate_key path/to/server.key;
}
A to je vše. Docela mazec, co? Otevřete v prohlížeči
https://localhost a jestli se stránka zobrazí, je to důvod
k oslavě.
Stránky Nette existují ve dvou jazykových verzích: české
a anglické. Udržovat tak obsáhlý projekt ve dvou mutacích vyžaduje dost
práce, ale vidím v tom smysl.
Plnohodnotná česká dokumentace a fórum je totiž výhodou pro zdejší
začínající programátory, protože žádný jiný framework ničím takovým
nedisponuje. Samozřejmě ideální by bylo, kdyby každý Čech už od
základní školy uměl plynně anglicky, ušetřilo by to hodně práce, ale
není úkolem frameworku tohle suplovat. Nicméně angličtina není
v žádném případě druhotným jazykem. Naopak. Posuďte sami:
Dokumentace. Její současná velikost
čítá 3 MB textů (pro srovnání celé
dílo Shakespeare má 5 MB). Anglická a česká jsou přitom zcela identické.
Nejsem si vědom, že by jeden jediný odstavec existoval třeba v české
verzi a anglické chyběl. Případně by se v jedné verzi objevil mnohem
dříve než v druhé. Obě verze jsou neustále synchronizované. Pokud byste
na nesoulad narazili, vytvořte prosím issue na GitHubu.
Anglické forum bylo spuštěno v roce
2008. Na českém až do minulého týdne svítila zpráva: „Chcete se
zdokonalovat v angličtině? Zkuste psát do anglického fóra. I když by to
bylo s chybami – těmi se člověk učí.“, takže i mnoho Čechů
používá anglické fórum.
Nette Blog v tuto chvíli čítá
34 článků v angličtině a 19 v češtině. Rozhodně doporučuji blog
sledovat, třeba přes RSS,
stává se z něj hlavní zdroj informací o novinkách.
Diskuse na GitHubu jsou výhradně v angličtině. Tuším od roku 2012 je
to oficiální podmínka. Jedinou výjimkou jsou diskuse o české dokumentaci,
což je snad pochopitelné.
V celém kódu se nikdy neobjevilo jediné české slovo. Kód je od
prapočátků pouze v angličtině, včetně všech chybových hlášek,
komentářů atd. Tuším jen jednou se v něm vyskytlo slovo fuck 
Dále je tu oficiální Twitter
kanál, který je od počátku kompletně anglicky.
Co naopak anglicky není? Tak především jsou to videa z Posobot a
facebooková stránka Nette Framework
CZ/SK, která slouží zejména k informování o lokálních akcích,
jako je právě Posobota nebo NettePivo. A taky kanál na Slacku
Péhápkaři, což tedy není oficiální součást Nette.
Ještě pár technických záležitostí: pokud přijdete na úvodní
stránku webu, fóra či blogu, nejspíš vás to přesměruje na českou verzi.
Je to pouze proto, že máte v prohlížeči nastavený jako preferovaný jazyk
češtinu nebo jste se už někdy v minulosti do české mutace přepnuli.
Jinak samozřejmě přesměrovává na anglickou verzi.
Taktéž je určitý rozdíl mezi výpisem článků či příspěvků na
českém a anglickém fóru. Web zkrátka předpokládá, že český uživatel
anglicky číst umí, takže českým uživatelům se například u nejnovějších příspěvků
vypisují i ty anglické nebo na českém blogu i anglické články,
u který neexistuje českých překlad. Zahraniční uživatel tento mix
nevidí.
Česká verze je zkrátka přidaným komfortem. Ale rozhodně preferujeme
tvořit obsah v angličtině.
Článek vyšel na blogu
Nette.
Content Security Policy (CSP) je dodatečný bezpečnostní prvek, který
prohlížeči říká, jaké další zdroje může stránka načítat a jak
může být zobrazena. Chrání tak před vkládáním škodlivého kódu a
útokům jako je XSS. Odesílá se v podobě hlavičky sestavené z řady direktiv.
Jeho nasazení ale není vůbec triviální.
Obvykle chceme používat JavaScriptové knihovny umístěné na různých
místech mimo náš server, například měřící kód Google Analytics,
reklamní systémy, captchy atd. A tady bohužel první verze CSP selhává.
Vyžaduje přesnou analýzu načítaného obsahu a nastavení správných
pravidel. Tedy vytvořit whitelist, výčet všech domén, což není snadné,
jelikož některé skripty dynamicky dotahují další skripty z jiných
domén, nebo jsou na jiné domény přesměrované atd. A i když si dáte
práci a seznam vytvoříte ručně, nikdy nevíte, co se může v budoucnu
změnit, takže musíte neustále sledovat, jestli je seznam stále aktuální a
opravovat ho. Analýza Google ukázala, že i to pečlivé ladění ve finále
vede k tomu, že povolíte tak široký přístup, že celý smysl CSP padá,
jen posíláte s každým požadavek mnohem větší hlavičky.
CSP level 2 už k problému přistupuje jinak, pomocí nonce, nicméně
teprve třetí verze řešení dotáhla do konce. Bohužel zatím (rok 2019)
nemá dostatečnou podporu u prohlížečů.
O tom, jak sestavit direktivy script-src a
style-src, aby správně fungovaly i ve starších
prohlížečích a přitom s tím bylo co nejméně práce, jsem sepsal podrobný
článek v partnerské sekci Nette. V zásadě výsledná podoba může
vypadat nějak takto:
script-src 'nonce-XXXXX' 'strict-dynamic' * 'unsafe-inline'
style-src 'nonce-XXXXX' * 'unsafe-inline'
Příklad použití v PHP
Vygenerujeme nonce a odešleme hlavičku:
$nonce = base64_encode(random_bytes(16));
header("Content-Security-Policy: script-src 'nonce-$nonce' 'strict-dynamic' * 'unsafe-inline'");
A vložíme nonce do HTML kódu:
<script nonce="<?=$nonce?>" src="..."></script>
Příklad použití v Nette
Protože Nette má vestavěnou podporu pro CSP a nonce od verze 2.4, stačí
v konfiguračním
souboru uvést:
http:
csp:
script-src: [nonce, strict-dynamic, *, unsafe-inline]
style-src: [nonce, *, unsafe-inline]
A v šablonách pak používat:
<script n:nonce src="..."></script>
<style n:nonce>...</style>
Monitoring
Než nastavíte nová pravidla pro CSP, vyzkoušejte si je nejprve nanečisto
pomocí hlavičky Content-Security-Policy-Report-Only. Ta funguje
ve všech prohlížečích podporujících CSP. Při porušení pravidel
prohlížeč nezablokuje skript, ale jen pošle notifikaci na URL uvedené
v direktivě report-uri. K příjmu notifikací a jejich analýze
můžete použít třeba službu Report
URI.
http:
cspReportOnly:
script-src: [nonce, strict-dynamic, *, unsafe-inline]
report-uri: https://xxx.report-uri.com/r/d/csp/reportOnly
Můžete zároveň používat obě hlavičky a v
Content-Security-Policy mít ověřené a aktivní pravidla a
zároveň v Content-Security-Policy-Report-Only si testovat jejich
úpravu. Samozřejmě i selhání ostrých pravidlech si můžete nechat
monitorovat.
Po dvou verzích PHP, které nepřinesly nic moc zajímavého, se blíží
verze, pro kterou bude mít opět smysl aktualizovat knihovny. Jde o PHP 7.4 a
hlavním tahákem jsou typed properties, které
uzavírají mnohaletý posun ke striktně typovanému jazyku, což PHP
zvýhodňuje oproti jiným webovým jazykům.
Ve zkratce, tahle novinka vám umožní deklarovat typy přímo
u proměnných třídy:
class Config
{
public string $dsn;
public ?string $user;
public ?string $password;
public bool $debugger = true;
}
Příklad použití najdete i v dokumentaci
Nette Schema, které je na ně už dnes připravené.
Je potřeba říct, že pokud jste si navykli používat privátní
proměnné a přistupovat k nim přes typehintované metody (což je
správně), tak vlastně o žádnou killer feature nejde. Druhotná kontrola
typů je zbytečná a vlastně jen zpomaluje kód. Diametrálně jiná situace
se týká public/protected proměnných, kde dosud neexistoval žádný způsob,
jak mít jejich hodnotu (a dokonce existenci) pod kontrolou. Až dosud.
Což nevyhnutelně povede k otázce:
Je nutné dál psát settery a
gettery?
Sice veškerý boilerplate kód nám dnes na kliknutí generují editory, ale
určitě vypadá hezky, když tohle:
class Circle
{
private $radius;
function setRadius(float $val)
{
$this->radius = $val;
}
function getRadius(): float
{
return $this->radius;
}
}
nahradíte za:
class Circle
{
public float $radius;
}
Nehledě na to, že i užití objektu je stručnější
$circle->radius = $x vs
$circle->setRadius($x).
Problém ale je, že velkou spoustu setterů a getterů nelze jednoduše
nahradit. Třeba zrovna v uvedeném příkladu by se hodilo ještě ověřit,
že poloměr není záporné číslo:
function setRadius(float $val)
{
if ($val < 0) {
throw new InvalidArgumentException;
}
$this->radius = $val;
}
A v ten moment už nelze kód zredukovat do veřejné proměnné.
Jindy zase chceme, aby jednou nastavená hodnota byla neměnná, což nelze
u public proměnné zajistit.
Nebo vůbec nechceme dávat k dispozici getter, protože nepatří do
veřejného API třídy.
Anebo chceme mít setter či getter součástí rozhraní.
Atd, atd.
Zkrátka někdy bude možné použít typované veřejné proměnné místo
metod, jindy ne, rozdíl bude dost často otázkou vnitřní implementace
třídy a pro uživatele neprůhledný. Což je cesta v nekonzistentnímu API,
kdy jednou se používá proměnná, jindy metoda a uživatel v tom nevidí
logiku. (Podobně jako třeba metoda PDOStatement::errorInfo() vs.
proměnná PDOException::$errorInfo).
Prohlubování nekonzistence ale nechceš. Raději konzistentní setrvání
u metod, privátních proměnných a všeho toho boilerplate kódu. A pro
privátní proměnné, jak jsem zmiňoval v úvodu, je přínos typehintů
sporný. Nebo ne?
V čem je tedy výhoda?
Vlastně je výhod dost, i když v jiných oblastech. Typované proměnné
budou užitečné pro kompilátor kvůli optimalizacím, pro práci s reflexí
nebo nástroje analyzující kód. Důležité budou v šedé zóně protected
proměnných. Umožňují zapsat prostředky jazyka to, co se dosud obcházelo
komentářem. A navíc přinášejí do jazyka nový příznak neinicializovaného
stavu, jakousi obdobu undefined z JavaScriptu.
Nette spouští nový
crowdfundingový program, jehož cílem je získat finanční prostředky
pro vývoj frameworku. Hlavní změnou je, že místo jednorázových
příspěvků je zaměřen na pravidelnou měsíční podporu. Ta může
přicházet jak od jednotlivců, tak od firem, kterým nabízí možnost
zviditelnit se na webu Nette a inzerovat na
fóru nebo přímo v dokumentaci, tedy na místech s nejlepším zásahem
cílové skupiny programátorů.
Každý, kdo staví na Nette, má zájem, aby se framework aktivně vyvíjel.
Aby podporoval nové verze PHP. Aby se opravovaly chyby. Aby přicházel s dalšími novinkami, které usnadní práci
nebo ušetří čas a peníze. Aby framework měl skvělou dokumentaci a
existoval kolem něj užitečný obsah, ať už ve formě článků, návodů
nebo videí.
Řada částí Nette představuje světovou špičku a chceme, aby tomu tak
bylo nadále.
Bez adekvátního financování se nic z toho nedá zajistit. Přitom abyste
se mohli spolehnout, že vyjdou další verze, stačí docela málo: abyste jej
každý měsíc podpořili byť jen malou finanční částkou.
Pojďte do toho a staňte se partnerem
Nette!
Používá vaše firma Nette?
Pokud pracujete ve firmě, které Nette vydělává peníze, vysvětlete
prosím svému šéfovi, že je dobrý nápad se stát partnerem a zajistit tak
zdravé fungování projektu, na který spoléháte. Zvýšíte prioritu
řešení vašich issues a zároveň zviditelníte svoji společnost
v komunitě a přilákáte k sobě vývojáře.
Partnerství totiž přichází s exkluzivními výhodami. Například
s uvedením vašeho loga na webu Nette, možností vkládat pracovní nabídky,
inzerovat na fóru (ukázka)
nebo v dokumentaci (ukázka),
tedy na místech se zcela nejlepším zásahem do skupiny Nette
vývojářů.
Partnerům vystavujeme faktury, aby si mohli podporu dát do nákladů, a to
buď měsíčně, čtvrtletně, půlročně nebo ročně.
Používáte Nette soukromě?
Stojíme také o vaši podporu. Přihlaste se k pravidelným donations přes
PayPal. Vaše jméno bude vidět na webu Nette.
Kolik peněz je potřeba?
V tuto chvíli máme stanoveny tři cíle, kterých chceme dosáhnout.
Prvním cílem je 64.000 Kč měsíčně, které zajistí, že se vývoji
bude věnovat jeden programátor na půl úvazku. Další vývoj Nette tak bude
pokračovat, nicméně polovičním tempem než dosud, což není úplně
ideální. Při dosažení hranice 128.000 Kč získá framework full-time
vývojáře a nové verze mohou přicházet každý rok.
Náklady jsou tak nízké proto, že nepotřebujeme kanceláře a hlavně
pracujeme na něčem, co nás baví.
Při dosažení třetí mety 196.000 Kč měsíčně budeme moci přizvat
další spolupracovníky a vylepšovat tak web, dokumentaci, vytvářet nový
obsah a nechat jej překládat do angličtiny. A tak oslovit zahraniční
komunitu. Čtvrtá meta dává možnost zapojit druhého programátora, což by
vývoj a správu issues značně zrychlilo.
Jakmile se dosáhne tohoto milníku, připravíme další cíle, které by
počítaly s více programátory, mohly by vznikat nové užitečné nástroje
a knihovny. Pak třeba vznikne i kniha o Nette.
Viz také Freelo.cz:
14 důvodů, proč podpořit Nette
How to mock classes that are defined as final or some of their
methods are final?
Mocking means replacing the original object with its testing imitation that
does not perform any functionality and just looks like the original object. And
pretending the behavior we need to test.
For example, instead of a PDO with methods like query() etc., we create a
mock that pretends working with the database, and instead verifies that the
correct SQL statements are called, etc. More e.g. in the Mockery
documentation.
And in order to be able to pass mock to methods that use PDO
type hint, it is necessary for the mock class to inherit from the PDO. And that
can be a stumbling block. If the PDO or method query() were final, it would not
be possible.
Is there any solution? The first option is not to use the final keyword at
all. This, of course, does not help with the third-party code that it uses, but
mainly detracts from the important element of the object design. For example,
there is dogma that every class should be either final or abstract.
The second and very handy option is to use BypassFinals, which removes
finals from source code on-the-fly and allows mocking of final methods and
classes.
Install it using Composer:
composer require dg/bypass-finals --dev
And just call at the beginning of the test:
require __DIR__ . '/vendor/autoload.php';
DG\BypassFinals::enable();
Thats all. Incredibly black magic
BypassFinals requires PHP version 5.6 and supports PHP up to 7.2. It can be
used together with any test tool such as PHPUnit or Mockery.
This functionality is directly implemented in the „Nette Tester“: https://tester.nette.org version 2.0 and
can be enabled this way:
require __DIR__ . '/vendor/autoload.php';
Tester\Environment::bypassFinals();
Jak mockovat třídy, které jsou definované jako final nebo
některé z jejich metod jsou final?
Mockování znamená nahrazení původního objektu za jeho testovací
imitaci, která neprovádí žádnou funkci a jen se tváří jako původní
objekt. A předstírá chování, které potřebujeme kvůli testování.
Takže například místo objektu PDO s metodami jako query() apod.
vytvoříme jeho mock, který práci s databází jen předstírá, a místo
toho ověřuje, že se volají ty správné SQL příkazy atd. Více třeba
v dokumentaci
Mockery.
A aby bylo možné mock předávat metodám, které mají type hint
PDO, je potřeba, aby i třída mocku dědila od PDO. A to může
být kámen úrazu. Pokud by totiž třída PDO nebo metoda query() byla final,
už by to nebylo možné.
Existuje nějaké řešení? První možnost je final vůbec
nepoužívat. To ovšem nepomůže s kódem třetích stran, který final
používá, ale hlavně se tím ochuzujeme o důležitý prvek objektového
návrhu. Existuje dogma, že každá třída by měla být buď final, nebo
abstract.
Druhou a velmi šikovnou možností je použít Nette Tester, který od verze 2.0 disponuje
vychytávkou, která odstraňuje z kódu klíčové slovo final
on-the-fly. Stačí na začátku testu zavolat:
require __DIR__ . '/vendor/autoload.php';
Tester\Environment::bypassFinals();
A je to. Je za tím ukrytá neskutečně černá magie 🙂
Pokud nepoužíváte Nette Tester, ale třeba PHPUnit, nebudete ochuzeni,
stačí si nainstalovat BypassFinals:
composer require dg/bypass-finals --dev
A na začátku skriptu zavoláte:
require __DIR__ . '/vendor/autoload.php';
DG\BypassFinals::enable();
