Názory k článku Oprava chyby Nette: jak jsme si poradili se zranitelností nejvyšší závažnosti
-
Random Guy (neregistrovaný)
Postavit komercni reseni na frameworku ktery stoji na 1 cloveku muze jenom blazen. Nic ve zlym. https://nette.org/cs/about
-
- - (neregistrovaný)
Ono to reálně nestojí jenom na jednom člověku [2] a jak vidíte, tak např. testoval to někdo jiný ...
Když se podíváte na github hlavního balíčku [1] z 42, tak je tam 21 pull requestů od různých lidí, poslední ze září. No, Symfony to není, ale dobrý. Nedávno jsem stahoval nějaký React project a ten měl 2500 závislostí, nějakých 10 zrovna outdated a kdoví kolik z nich je one-man show. Tipnul bych že dobrá polovina....
[1] https://github.com/nette/application/pulls
[2] https://github.com/orgs/nette/people29. 10. 2020, 08:48 editováno autorem komentáře
-
Tak zrovna core knihovny v linuxu sice maji maly upstream vyvoj ale muzu zarucit ze v RH nebo SUSE by se naslo nekolik lidi co by to opravili.
Kdyz upstream nereaguje tak to proste opravime protoze si nemuzeme vetsinou dovolit tam ty security diry zustat.Samozrejme nikdo nebude nervozni kuli necemu s malym CVSS ale 7+ si rozhodne poresime a dodame upstreamu.
-
Problem byl, ze odezvy se zacaly misto v sekundach pohybovat v minutach. A misto aby se resil kod, pridaval se hardware. Duvody tehdejsich hlavnich programatoru byly, ze kod je v poradku, lip to udelat nejde a protoze cast jich byla z nette komunity, tak se problem hledal jinde. Nakonec, kdyz to bylo neudrzitelne, v tichosti se projekt ukoncil. Pak to par lidi nad stejnymi daty prepsalo do Pythonu a odezvy byly zas do 5s.
-
- - (neregistrovaný)
@bunak
To je zajímavé, protože Python je často referován jako obecně pomalý (až na některé knihovny, které byly ad-hoc napsány v C kvůli výkonu. To ne, že bych si myslel, že to nevíte, ale nechci, aby mě tu za to někdo tahal další dva dny, tak to píšu zrovna)
Vypadá to, že příčina je tohle "A misto aby se resil kod, pridaval se hardware". Otázka tedy je, jestli závadný kód je skutečně Nette. Není to tak dávno a nebylo to ani poprvé, kdy jsem optimalizoval po někom v kódu takové kusy jako:
func param:
array $entities /* num: 50 */
for each $entity:
remote database call for 30 child entities
match 5 and use some labela to konkrétně v Symfony s tím, že Doctrine je prej optimalizovaná a Symfony je cachované. Nicméně musí i tak udělat 50 requestů zvlášť.
A když takových kusů máte po cestě 10 (třeba API projekt), tak Vám rychlost random kolísá během dne a žádný extra peek není vidět.To jenom pro tak ukázku, přišlo mi to na mysl Otázka vlastně jenom je, kterou částí kódu to bylo.
29. 10. 2020, 13:29 editováno autorem komentáře
-
"a rozhodne bych na nem nestavel velka reseni."
tohle ctu na forech v diskuzich o vsech webovych frameworcich. Podle mych zkusenosti u webovych aplikaci na kodu samotne aplikace ani tolik nezalezi, dulezita je infrastruktura okolo, testy, CI, architektura DB.
Za me, nektere feaury Nette bych radeji nepouzival (snippety), ale vetsina je kvalitni, (hlavne formulare).
-
No popsal jste právě to, co mají asi ti ostatní na mysli. Ten, kdo zvládá infrastrukturu, arichitekturu, testy, CI, dobře navrženou DB - tomu je 90 % "výhod" Nette frameworku k ničemu, protože buďto nemá dotažené některé pokročilé funkce, nebo řeší problémy, které se právě lépe dají řešit architekturou.
Formuláře Nette jsou OK, pokud Vám stačí běžné formuláře. "AJAX" má Nette žalostný (ani bych to nenazýval ajaxem) - takže i tuto výhodu u větších řešení moc nevyužijete.
-
Já neříkal a neříkám, že Nette nemá své místo. Tvrdím ale, že není vhodné, pokud je perspektiva růstu projektu do větších rozměrů.
Jestli potřebujete projekt, který poběží na jedné adrese, nepotřebuje rozdělit frontend a backend, formuláře Vám stačí neaktivní nebo se základním ajaxem, a za databázi považujete MySQL (nebo Postgres degradovaný na schopnosti MySQL), pak je Nette naprosto OK. Do této definice se vejde 90 % projektů.
-
- - (neregistrovaný)
@Miroslav Šilhavý
1. Co přesně Vám v Nette brání mít front-end např. React?
2. Co přesně Vám v Nette brání přidat vlastní cally do formulářů?
3. Co přesně Vám v Nette brání použít jakoukoliv jinou databázovou knihovnu kterou nabízí PHP?
4. Co přesně Vám v Nette brání nainstalovat a použít jakýkoliv Composer balíček nebo rozbalit libovolnou php knihovnu?Preferuji odpovědi, které obsahují přesně. Děkuji.
1. 11. 2020, 13:37 editováno autorem komentáře
-
@87vdf4vg82
Absolutně nic mi v tom nebrání, jen pak z Nette zbude jen pahýl, který už moc nepřináší a rovnou můžu vzít třeba Symfony. S tím rozdílem, že se Symfony jsou balíky lépe udržované, mají inteligentnější číslování apod.
Nette, a to prostě tvrdím, je skvělý framework as-is. Jakmile už potřebujete kombinovat s Reactem, vzít jinou DB knihovnu, nahradit další věci balíčky z composeru (nemluvím o doplnění funkcí, ale o nahrazení těch standardních), je už Nette přítěží.
-
"tomu je 90 % "výhod" Nette frameworku k ničemu"
to je pripad vsech frameworku, ktere necili ciste na single page aplikace. Casti, ktere nepotrebujete, proste nepouzijete.
"Formuláře Nette jsou OK, pokud Vám stačí běžné formuláře. "AJAX" má Nette žalostný (ani bych to nenazýval ajaxem) - takže i tuto výhodu u větších řešení moc nevyužijete."
formulare maji resit v prve rade validaci dat, forma odeslani vysledku je na vas, odeslani v JSONu je trivialita.
-
- - (neregistrovaný)
To je spíš ukázka toho, když se cokoliv nezáplatuje včas.
Nakonec to Nette ale není tak zlé?
"To je skvělá zpráva, pokud by se v tomto nástroji neobjevila první závažná zranitelnost po 13 letech…"
[https://viry.cz/tisice-ceskych-webu-je-nutne-zaplatovat/]29. 10. 2020, 13:43 editováno autorem komentáře
-
Asi různě chápeme to "speciální" :) pro mě "copy & paste z dokumentace" presenteru není speciální. Pod speciálním bych si představoval nějaký šílený fuzzy string který vyvolá buffer overflow v parseru a spustí shellcode. Na
GET /nette.micro?callback=libovolná_php_funkce_kterou_chceme_spustit&arg1=x&arg2=y...nic speciálního nevidím... funkce shell_exec, a už mi stovky útočníků prohledávali kontejnery a instalovali rootkity.
