Názory k článku
Naučte se principy moderního JavaScriptu (školení)
-
anon (neregistrovaný)
s javascriptem na serveru je problem, ze se zacal risit pres nodejs protoze tak javisti objevili async a pak zacali vsechny knihovny prepisovat do javascriptu, kdyz napises milion a miliony (zbytecne) novyho kodu ... co z toho bude? tisice a tisice (bezpecnostnich) problemu.
Zvlast co se tyka bezpecnostni, tak radu best (co best, essential!) practices lidi kolem nodejs proste ignoruji.
Vypada to pak podle toho.
O jazyk jako takovy ani nejde.
-
anon (neregistrovaný)
znam dost technologiiv kterych zranitelnosti uz bylo objeveno tisice a ted to nekdo prepisuje a ty "ify" co nechape vynechava ...
prikladu vaznych chyb v nodejs jen za posledni rok je nemalo .. ale nejde o verejne chyby, jde o ty neverejne.
Rikam, to "za chvili" zas budou prepisovat znova,
hadam navrat k statickemu typovani RemindMe! 10 years -
anon (neregistrovaný)
A ten priklad ... z praxe, takto to funguje prakticky vsude kde se pouziva nodejs = naprdim si do zavislosti tisice knihoven, ktere zavisi na dalsim tisici knihoven, locknu to verzi a kterou jsem to jakztakz otestoval a mam hotovo, bojim se na to sahnout dokonce ;). A ted vetsina tech knihoven jsou one man show, ktere nekdo dal narychlo dohromady za posledni dva roky. Audit nula.
Sranda je ze s npm ani ten lockne zavislosti nefunguje spravne - prtz zavilost kterou mam na primo, muze mit zavilost danou dynamicky, ta se zupdatuje a vse se rozbije. Z praxe :).
K zamysleni ... co tohle dohromady znamena ?
Argument, ze se jedna o konkretni pouziti a blablabla a ze to tak delaj borci stejne v pythonu a ruby. Rozdil je samozrejme v mire v ktere se to bastli, nejde o jazyk jako spis o zvyklostikolem toho.
Osobne nemam prob to bastlit v corpu v javasriptu :)
-
anon (neregistrovaný)
treba kerberos knihovna pro nodejs. Vybrakovana z pythonu (kde za tou python knihovnou stoji sice apple ale uz v tom pythonu to je celkem bastl, neco jsem tam opravoval a to jejich svn byla celkem sranda, na pipy se jim to povedlo nahrat az na podruhy), navic i ta nodejs knihovna ma python jako build dependency
-
anon (neregistrovaný)
Verejne chyby si najdes normalne v databazich CVE.
K te druhe otazce, zkus se zeptat jinak. Tak jak se ptas to vypada, ze si myslis ze technologie ve ktere najdes exploitovatelnou chybu po pul roce badani je stejne bezpecna jako technologie, kde ty chyby skoro ani nemusis hledat. V obou pripadech je to >0.
Jestli to pouzivas spokojene v praxi tak bud rad, prijde mi debilita se o tomhle hadat. Jen ukazuju priklady k zamysleni. "Moc importu" je z pohledu bezpecnosti spatne, to je jedna z tech zakladnich poucek, cool termin je "attack surface reduction" :).
PS: jaktoze uz nemam 30 minusu na kazdy prispevek potom co jsem upozornil na ten script co ty minusy posila? :(
-
null null (neregistrovaný)
@anon
K první otázce? Ta otázka zněla, ať dáš něco konkrétního ke: "Zvlast co se tyka bezpecnostni, tak radu best (co best, essential!) practices lidi kolem nodejs proste ignoruji."Sorry, ale "podívej se do csv" je odpověď nedostatečná. Jeden by si začínal myslet že jenom tak plácáš ....
Jak jinak se mám zeptat? Rozčiluješ se tu nad tím, že v JS jsou chyby a zranitelnosti. tak se ptám, kde nejsou?
""Moc importu" je z pohledu bezpecnosti spatne"
Ok. Co je to moc importu? 1, 5, 15, 150 ... kdo to rozhodl, kolik je to číslo?
"PS: jaktoze uz nemam 30 minusu na kazdy prispevek potom co jsem upozornil na ten script co ty minusy posila? :("
To bude spíš tím, že se nikomu ty tvoje bláboly nechce číst, ne tak ještě na něco klikat ...
-
anon (neregistrovaný)
To si nepochopil. "Koukni na CVE" byla odpoved jak si se ptal na verejne zname zranitelnosti.
Ty prusery s nedodrzovanim konkretnich "best practices" pak rozebiram pomerne detailne. Jestli ti prijde v cajku stavet verejne pristupnou aplikaci na kodu od tisicu lidi co nejak nahodne placli na github, *audit zadny*, kdykoliv ho muzou zmenit (a pak zmenit zpatky; nekdo nam ukradl pristupove udaje ke gitu!), v poradku, no podle knihy to fakt neni.
Zajimavy ze je prestalo bavit klikat zrovna v ten moment co jsem zminil ten minusovaci script :).
-
null null (neregistrovaný)
@anon
Ale já se neptal na na veřejně známé zranitelnosti, já se ptal na něco konkrétního k "Zvlast co se tyka bezpecnostni, tak radu best (co best, essential!) practices lidi kolem nodejs proste ignoruji.". Třeba co teda inorují?
Co rozebíráš detailně? Jenom nějaké dojmy o tom, co "je moc importů"".
Kdo co plácl náhodně na github- jak jsi to poznal?
"Zajimavy ze je prestalo bavit klikat zrovna v ten moment co jsem zminil ten minusovaci script :)"
No určitě ti to dělají schválně. Nenech se vykolejit ...
-
Přesně, jsou tu různí "experti", kteří tuto kombinaci nenávidí. Ty jazyky za to ale nemohou. Jo, mají chyby, ale nic fatálního. Prasata budou vždy, i se sebelepším jazykem. Nicméně já místo MySQL už hodně používám MariaDB, ale ta z ní vychází no. :-D A PHP už jen od sedmičky vejš, jen je někdy radost do toho přepisovat stařičké mini projekty.
-
Ja jsem na javascript zanevrel zacatkem tisicileti, kdy bylo nemozne neco napsat, aby to fungovalo i na exploderu. Mam krasnou knihu o javascriptu, u kazde druhe funkce je poznamka - "nefunguje na ie6", "nefunguje na netscape < 4" a tak dale. Jazyk jako takovy se mi celkem libil, je videt, ze ho vymyslel nekdo kdo mel nejakou koncepci, ale zabily ho nekompatibility.
Ovsem hlavni problem javascriptu a podobnych scriptovacich jazyku je, jak uz nekdo zminil prede mnou, to, ze chybu najdes az kdyz testujes. Zrovna nedavno jsem delal spoustu uprav do C++ projektu - po napsani jsem stravil pul dne jenom spravovanim erroru kompilace. Preklepy ve jmenech, zapomenute stredniky, zapomenuti nadefinovat funkci, kdyz uz ji volam a podobne. Tohle vsechno bych si v javascriptu usetril, tam by se to projevilo az pri testovani, az by se program dostal do tohoto konkretniho mista. To bych ladil jeste ted.
Ovsem na napsani neceho rychleho jednoducheho samozrejme preferuju scriptovaci jazyky (treba bash nebo lua).
-
javascript aficionado (neregistrovaný)
pisete 20 let stare nesmysly, ze vy ste se zastavil v roce 2000 je vas problem. dnesni kompatibilita mezi browsery je na velmi dobre urovni co se tyce ES6 (coz je tp hlavni co chcete pouzivat).
Dale si stezujete na staticke typogani a pak mluvite o preklepechncoz vam bezny linter odchytne.
v js se dnes vsude testuje , juknete na jest.
pokud chcete staticky typovani mate tady stale popularnejsi typescript.
ta poznamka o tom ze se vam ten jazyk tehdy libil ze ma koncept je dost srandovni kdyz vezmu v potaz ze puvodni clovek to napsal za 2 tydny a na internetu je to slavna historka. (vtipnejsi uz snad je jen pan lardof s jeho nepochopenim stringunv perlu a pointeru v c++, a jeho nasledny paksvil php).
ja mam mimochodem doma taky knizku s turbo pascalem a veril byste ze v ni nelistuju dneska uz?
-
Karel (neregistrovaný)
Trochu off topic, ale nedá mi to.
Coby vzděláním strojař vždycky pláču, když někdo začne mluvit o testech jako garanci kvality. Každý inženýr z nějakého "hw" oboru, každý kvalitář, i obyčejný mistr ve výrobě vám řekne: kvalita se nedá vykontrolovat, kvalita se musí vyrobit. Testy a kontrola kvality je jen ověření, že to je uděláno dobře. V oboru SW je teď móda přístup "nemám chuť ani čas to po sobě zkontrolovat, tak spustím testy a uvidím". V oboru HW je něco takového nepřípustné. Představuji si zedníka, co něco nahází do míchačky a pak s tím zkusí postavit kus zdi. A když se to rozpadá, tak teprve pak kontroluje, zda tam není třebas málo vápna nebo jestli nezapomněl na cement.
Navíc si na testech vylámu zuby každou chvíli. Doteď kupříkladu nemáme vyřešený problém, že jedna procedure když dostane v jednom parametru místo 1 nebo 2 hodnotu 3, tak to celé zbuchne na "nemůžete vložit NULL do NOT NULL sloupce X v tabulce Y". A experti autoři se už dva týdny nemohou dohodnout, jak to má být správně. Já jediný co po nich chci je rozumná chybová hláška. Třebas "3 není povolená hodnota", nebo "chybí údaje o zákazníkovi", případně "nelze uložit záznam o stornu transakce". Ne, oni už dva týdny řeší, kde v celém to řetězu volání je chyba. Ten řetěz je zrhuba takhle:
1. Hodnota 3 znamená, že se jedná o ověřeného zákazníka. Procedura ale nemá žádný parametr, kam by se to id zákazníka dalo předat.
2. Procedura volá jinou, pro kterou některé údaje dohledá. Ta už parameter s id zákazníka má, jenže je do něj dáno natvrdo NULL.
3. V kaskádě to dojde do místa, kde se ověřuje kredit zákazníka. Jenže tím, že id zákazníka je NULL, tak nejde nic načíst a vyhodí to výjimku NO_DATA_FOUND.
4. Zpět v kaskádě to odchytne výjimku a připraví si hlášku "Customer credit exceeded". Bohužel to po sobě chce zamést stopy a stornovat transakci. Zavolá to proceduru pro storno transakce.
5. Procedura si načte údaje o transakci, mimo jiné částku transakce. Jenže žádná nevznikla, takže částka je NULL. Pak udělá rollback. Jako poslední se pokusí zapsat do tabulky zamítnutých transakcí informaci o tom, že nějaký pokus byl. No a tam je ten sloupec s částkou, který nedovolí NULL a vyhodí to výjimku. A protože ta kaskáda už je v bloku ošetření výjimky, tak to vyhučí až na klienta.No a oni teď řeší, která z těch procedur je vlastně špatně a jak upravit testy. Já mám pocit, že špatně jsou úplně všechny. Ta první má odmítnout hodnotu 3, protože zákazníka ani nebere. Ta druhá by měla udělat to samé. Ta kaskáda v bodě 3 by také měla být ošetřena jinak a ne se pokusit o čtení a doufat že o dvě úrovně výše to chytne WHEN OTHERS. Bod 4 nejprve vybere špatnou chybovou hlášku (má být zákazník neexistuje, nikoliv že má vyčerpaný kredit) a pak je také otázkou, proč se pokouší stornovat transakci, o které může vědět, že nevznikla. No a bod 5 je špatně tak nějak úplně - tam má být nějaká kontrola, nebo NVL apod. Tahle procedura prostě nesmí skončit výjimkou, protože tím překryje ty skutečné.
A víte co je na tom nejlepší? Že tihle lidé zkoumají to, jak by se to mělo chovat, nikoliv ze specifikací, ale právě z testů. Nesnáším testy. Ty mají být na build serveru a má to být předposlední linie obrany. To nemá být nástroj programátora v duchu "když to projde, tak dělám push a pull request". Aby tak použít šly, tak by musely testovat všechny možné kombinace. Jenže to nejde, těch je prostě moc. A není to jen o kombinaci vstupních parametrů, ale i o stavu proměnných, záznamů v databázi atd.
Takže ne, i kdyby se lidé na hlavu stavěli, tak tvrzení "v js se dnes vsude testuje" je nepravdivé (testy pokrývají sotva procento možných kombinací) a hlavně to není cesta kupředu. Proč se tolik programátorů odklání od "dvakrát měř, jednou řež" k pohodlnému "uříznu, změřím a kdyžtak to uříznu znovu"? Před 25 lety byl vtip: programátor je člověk, co umí psát, ale neumí číst. Dnes to není vtip, dnes je to realita. Spoléhat na testy, že vám řeknou, kde máte co špatně? Proboha!
-
Ondra Satai NekolaZlatý podporovatel- Testy mohou byt specifikace.
- Rozlisuj "test before" a "test after"
- zamysli se nad otazkou pokryti testy (navic trebas s mutacnim testovanim a s property based testovanim)
- cast zminovanych problemu resi, pokud je kod "pure"
- hodne z toho, co ti vadi, lze pokryt striktnejsim typovym systemem, ale to ma zase nejaka jina negativa -
Karel (neregistrovaný)
Ano, přesně jak píšete.
Testy jsou specifikace. Pro kombinaci vstupů, kde jako typ autorizace je uvedeno 3 (ověřený zákazník) není test, spadne to na hubu a nikdo vlastně neví, co by to správně udělat mělo. Testů je tam hned několik pro 1 (platil cash) nebo 2 (platil kartou), ale pro 3 tam není nic. Přitom je to povolená hodnota uvedená v seznamu autorizačních metod. Jenže právě jak píšete - nikdo to nepokryl testem a specifikaci po 14 letech nenašli. Tak se teď snaží dobrat k tomu, zda tam hodit podmínku, že to nesmí být 3, nebo zda tam doplnit jako parametr id zákazníka. Bohužel netuší, zda by to pak fungovalo. Respektive ví, že to nefunguje, ale netuší, co s tím. Testy to sice úspěšně projde, jenže to neponíží kredit u zákazníka. Což asi chyba bude, tam zjevně chybí volání nějaké procedury, co k zákazníkovi zapíše, že si koupil cosi za XY korun. Jenže kde a jaká? Test nenapoví.
U odrážek 2 a 3 jsme na tenkém ledě právě u lidí, kteří rezignují na typové kontroly, desk checking apod. a spoléhají se právě na pokrytí testy. Dělají to, co píšete - rozlišují, zamýšlí se. Každé dva roky přijdou s jiným testovacím frameworkem. A celé ty roky to stejně probíhá stejně - vrací se jim tickety, protože aplikace padá. Oni dokonce mají 80% ticketů vrácených už při code review. Jejich typická reakce je "opravil jsem překlep a doplnil test". Kdyby to fungovalo, tak by to přece mělo na testech havarovat a počet ticketů, co to navzdory chybám dotáhnou až na code review, nebo dokonce na QA, by měl klesat, ne? Neklesá. Jen roste počet testů, které stejně nijak nepokryjí tu další chybu, co tam zavlečou. Slušně to zabírá snad jen při refactoringu, ale i tam se jim běžně stane, že test projde, přestože aplikace bliká jednu chybovou hlášku za druhou.
Jediné co se časem zlepšuje jsou testy, co dělá QA. Ti mají nástroje co simulují uživatele, klikají, volají API atd. Jenže to je to nejdražší testování. Tedy ne, dražší je ještě testování zákazníkem, ale tam to naštěstí obvykle nedoputuje.
Osobně z toho viním lidi. A pak média a literaturu, která v těch lidech podporují iluzi, že nějaké Unit Testy, System Testy, Integration Testy atd. mohou nahradit kontrolu kódu. A na tom pak staví ještě šílenější konstrukci, že není potřeba nic jako defenzivní programování, protože chyby odhalí už IDE a co ne, to odhalí testy. A to je to, z čeho mě mrazí. Programování stylem "pokus omyl". Proto reaguji tak podrážděně na všechny "od toho jsou testy".
-
anon (neregistrovaný)
Mas naprostou pravdu Karle, u vyvoje software se obecne na kvalitu kasle nehorazne.
Ale na root si to psat nemel, to si zase vyslechnes pseudomoudra od lidi co ten zpraseny kod pisi ;)
Chtelo by to fakt zodpovednost pro manageri a vyvojare a realne tresty. Kdyz spadne most, take se vysetruje kdo za to muze.
Kdyz nekdo zmrvi software, kdy to treba milion lidi sroji 5 minut casu kazdy, zodpovednost zadna. A prepocitej si kolik je to zivotu.
-
Yak (neregistrovaný)
Kašle. Ale takove je casto rozlozeni poptavky. Tedy ne po nekvalite, ale casu a cene. Kdo chce kvalitu, musi si ji ve finale zaplatit. Kdo chce vyrabet kvalitu, nemuze byt levny. Samozrejme nejake zakladni minima a normy tam jsou, ale takto to funguje i v jinych odvětvích. Tim neomlouvam ruzne prasarny, ale ne vzdy je za kvalitou jenom neumetelnost. A vstupuji do toho dalsi vlivy. Napr.: dostanes vyrobit nejaky modul, prvni testy jsou ti naplanovany za 14 dnu s tim, ze se posoudi moznosti a rozhodne se o dalsim osudu. Vyrabis proof of concept, prototyp, ... po testu se nekdo z vedeni, treba majitel - neprogramator, rozhodne ze to staci a zitra to jde do produkce, protoze jim stoji jiny projekt - treba dulezitejsi. Tvuj prototypovy kod ie v produkci - jak moc velke jsi čuně? Kolikrat kvuli tomuto zmenis job?
-
Jaro (neregistrovaný)
Skriptovací jazyky jsou fajn na rychle prototypovan. Bohužel JS programátora "nevede" ke strukturovanemu kódu. Pro "velke" aplikace bych použil nějaký objektový jazyk - Javu, C# nebo C++. Zvláštní kapitolou je "moderni" frontend v REACTu, Angularu či necem podobném. Ve větších projektech potřebujete cca 3 frontendaky na jednoho backendistu - což je ekonomický nesmysl, který je dlouhodobě neudržitelný. V jedné opravdu velké firmě, kde jsme bastlili frontend nám říkali pohrdlive Nintendos- Prostě jen hezky prezentujete nějaká data. A měli pravdu - tolik casu/peněz provarit pouze na frontendu je blbostí.
