Správičky 2 799 Blogy 945 Fórum 18 557

Zaujímavosti zo sveta

13.05 Antispam report Exchange 2013/…
blogCZSK
Nedávno jsem se setkal s prosbou, zda je možno udělat report nad funkcionalitou antispamu Exchange a trošku jsem narazil na problém, jak dos…
13.05 Pozvánka: konference, workshop…
blogCZSK
Níže jsme pro vás připravili přehled akcí, které jsou pro vás připraveny v příštích několika týdnech. Coding Bootcamp 19. 5. 2016 – Praha V …
12.05 Pozvánka: Nástroje a služby pr…
blogCZSK
Od vývoje přes nasazení po správu napříč platformami Rádi byste optimalizovali vývoj svých aplikací na různé platformy a nevíte jak? Zajímá …
12.05 System Center Configuration Ma…
blogCZSK
V minulém díle jsme nainstalovali SQL Server, který je nutný pro běh Configuration Manageru. Dnes nás čeká instalace WSUS, což je produkt, j…
11.05 Hovory od křivého stolu (5)
blogCZSK
A máme tu další díl českého video seriálu Hovory od křivého stolu (5). Pro toto vydání HKS jsme se ponořili do hlubin naší budovy a natočili…
11.05 Pozvánka: Coding Bootcamp Meet…
blogCZSK
V rámci pražského Coding Bootcampu budete mít možnost se naučit vše, co potřebuje moderní webový vývojář. Abyste měli představu, co bude náp…
10.05 Zajímavé kurzy a videa–MVA a C…
blogCZSK
I tento měsíc vám přinášíme výběr nejzajímavějších videí, kurzů a záznamů konferencí. Veškeré kurzy pak naleznete na portálu MVA a výuková v…
10.05 Azure Site Recovery – VMWARE (…
blogCZSK
Připravil jsem pro vás sérii článků, zabývající se technologií Azure Site Recovery. Konkrétně v šesti na sebe navazujících článcích se dozví…
09.05 DataScript: akční nabídka škol…
blogCZSK
Připravili jsme pro vás nabídku školení On-Demand. A jaké jsou výhody? nižší cena učíte se z pohodlí svého domova nebo kanceláře přístup mát…
05.05 System Center Configuration Ma…
blogCZSK
V předchozím díle jsme si nainstalovali prerekvizity potřebné pro běh Primary Site Configuration Manageru a také jsme připravili doménu pro …
20.04 Odkazy z prohlížeče – 20.4.201…
atasoft
CodeProject Video Transcoding and Streaming on the fly – CodeProject – přímo v prohlížeči (?) A Sample Code Submitted for Senior C# …
11.04 Linq a pracovní pohovor
mstr
Zjišťovat znalosti Linqu u pracovního pohovoru může být obtížné - s Linqem se asi setkal každý C# programátor, ale vždy záleží, do jaké hlou…
08.04 Linq - k čemu použít Aggregate…
mstr
K jednomu z předchozích článků, ve kterém jsem dal k dispozici cheatsheet pro Linq, se mne jeden známý zeptal, k čemu že je dobrý Aggregate …
27.03 Bezpečnost – věc veřejná
Poslední březnový den se v Praze uskuteční jednodenní konference o počítačové bezpečnosti SecPublica 2016. Jejím heslem je "securitas, res p…
16.03 Příklad na pohovor s programát…
mstr
Na blogu jsem uveřejnil několik příkladů z pohovorů s uchazeči o místo programátora. Dovolím si tedy uveřejnit jeden z dalších možných příkl…
15.03 IDisposable v příkladech
viga
Rozhraní IDisposable slouží k uvolnění “unmanaged” zdrojů. Nejčastěji to jsou různé objekty z Win32API (otevřené soubory, síťové spojení, GD…

Zabezpečenie vstupov ASP.NET MVC aplikácie

harrison314 - 22. 9. 2017 9:31 - 1990 views

Zdravim,

trochu to tu rozprudim, pridavam linku na vlastny clanok o zabpeceni vstupov ASP.NET (Core) aplikacie. 

http://harrison314.github.io/ZabezpecnieAspMvc.html

Snad niekomu pomoze, pri zabezpecovani nestandardnych vstupov. Dikusii sa nebranim.


harrison314

Článkov: 0, Správičiek: 6, Príspevkov vo fóre: 193, Príspevkov v blogu: 0, Bodov: 1085
Najaktívnejší č.: 24
Profil používateľa

Reakcie

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 23. 9. 2017 19:23:49 liero

ja som myslel, ze to tu rozprudil @johnnyhenderson :D

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 11. 10. 2017 9:52:23 liero

Je to dobry blog v tom, ze nazorne ukaze niektore uzitocne API z asp.net core frameworku.

Ale snad by sa patrila zmienka o tom najjednoduchsom a najstanadrnejsom sposobe validacie modelu cez DataAnnotation a CustomValidationAttribute, pripadne iny validacny framework, napr FluentValidation



BTW, nespomenul si verziu MVCka. v 2.0 sa toho dost zmenilo.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 12. 10. 2017 15:56:19 harrison314

Validacia cez DataAnnotation a CustomValidationAttribute ci FluentValidation, su podla mna na validaciu vstupu od pouzivatela. Ja som sa zameriaval skor na vstupy, ktore su vygenerovane strojovo a pri zabezpeceni sa na ne casto zabuda.
Ono to co je v blogu som bol nuteny vymsliet vdaka velmi paranoidnemu pracovnemu prostrediu :D

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 13. 10. 2017 8:39:04 liero

ok, moze byt

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 14. 10. 2017 7:55:11 T (anonym)

Lepsie/univerzalnejsie je pouzit JSON Schemu na validaciu vstupov API (analogia voci xsd scheme pri SOAP). Obecne, ludia su prasce a miesto toho, aby si napisali WSDL a z neho generovali kod, tak si nechaju generovat WSDL z kodu - napr. na UPVS asi ziadne API takto nie je riesenie a je to tragedia. (okrem toho, ze maju skaredy, matuci a necitatelny popis API cez WSDL, su derave a nevyuziju prve miesto, kde sa da komplexne a jednoducho vyriesit nekontextova validacia a na zaklade coho sa moze odmietnut vstup skor ako sa zacne procesovat runtimeom)

Podobne je to aj pri REST/JSON rozhraniach, kde pouzitie JSON schemy je skor rarita ako fakt.

Tento ako v clanku a podobne pristupy by som pouzil len ak sa jedna o nejake "raritne" vstupy, ktore som sa rozhodol doplacat do web aplikacie.(return url, nejaky confirmation code, na ktory nechcem robit separate api a pod.)

Staticku validaciu vstupov v sirsom kontexte, ako je naznacne v uvode clanku, teda ak sa jedna o riesenie vstupnej validacie pre remote facade (service)a fakt mi zalezi na dobrej statickej validaci, by som riesil cez JSON schemu. Okrem toho, ze ziskam komplexny popis api pre konzumenta mu zaroven davam nastroj na validaciu sprav na jeho strane. Otazka, aka by bola najlepsia implementacia pri core 2.0

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 14. 10. 2017 10:59:25 harrison314

Osobne sa JSON chemy bojim, je na to milion standardov, ktore ani nie su standardy...
S WSDL-kami uplne suhlasim, dokonca som robil nieco podobne.
Ono validovat JSON a XML dokazu aj firewally (WAF).

Ano presne na to je to urcene. Nechcem pisat blog o niecom, co uz bolo milionkrat vyriesne.

Co sa tyka REST-u na ASP.NET Core, tak by som sa kludne uspokojil s validacnymi atributmi. Pretoze sa ti vsteupy nedostavaju do HTML-ka.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 14. 10. 2017 15:59:48 T

Blog bol ok, v tom zmysle ako napisal liero, treba podpiskutovat o hraniciach kedy to uz takto neriesit. Inak JSON schemu som este nevidel pri Web Api vyriesenu nikde zatial, a uz vobec nie pri core, nemal by to byt problem ale z hlavy neviem, ako by som to riesil.

jj, dokazu ale validacia na WAF nesmie nahradzat validaciu na aplikacnej urovni, je to dalsia uroven obrany.(pokym sa len shareuju validacne schemy, straca to trochu zmysel a komplikuje change management, takze treba zvazit). Zmysel to ma hlavne tam, kde developeri boli lajdaci, nie je moznost dorobit do aplikacie validacie, alebo naozaj je nutne nezavisle validovat alebo WAF vie lepsie zuzitkovat informaciu o posielani nevalidnych requestov.(aj WAF uz dnes implementuje kadekto a casto robi len drahy prietokovy ohrievac)

posleny odstavec som nepochopil.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 14. 10. 2017 22:11:29 @T (anonym)

@T: Videl som takych ludi, co pisali wsdl rucne. Vygenerovany kod bol potom hrozny, lebo to co napisali sa potom nedalo namapovat na OO jazyk, hoci samotne wsdl vyzeralo cool. Lenze ja sa nepotrebujem pozerat na wsdl, ale na kod.

Co sa tyka validacie na urovni schemy - taka schema sa da docielit aj code first pristupom, je to len otazka generatora.


Samozrejme treba zobrat do uvahy, kto je konzumentom daneho webservicu. Ak je to nejaky verejny endpoint, tak samozrejme je ocakavana kvalita schemy vacsia. No minimálne sa treba zamysliet, ci v konkrétnom scenary ma taka validacia vobec zmysel, alebo je to len boj s veternymi mlynmi.

Co sa tyka JSON schemy a WebPI, tak ja generujem swagger ku kazdemu svojmu webapi projektu automaticky. Specialne asp.net core team smeruje k tomu ze swagger a ine podobne standardy budu podporovane out-of-the-box.

Myslim, ze by nebol problem generovat nejaku validaciu do schemy ani z tychto custom typov, ak byto bolo potrebne

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 14. 10. 2017 23:01:42 Liero (anonym)

Posledy prispevok som pisal ja, sorry

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 14. 10. 2017 23:34:46 T

@???:
"ja som videl"...
ano aj ja som videl...tie code first interfaces a bohuzial som s nimi musel aj neraz pracovat a doprial by som ich tvorcom, aby s tym skusili sami pracovat..

vygenerovany kod zo sofistikovaneho wsdl?...a nic strasne to nieje, treba si realne skusit(samozrejme aj tu treba trosku mysliet na to, co z toho vylezie, ale realne to nie je problem, ovela menej bolestne, ako za snazit z code first wcf generovat silne wsdl)...

wsdl ma vyzerat "cool", pretoze to o.i. popisuje contract pre konzumenta. To ako vyzera potom kod je len vecou generatoru alebo frameworku. Samozrejme, uplne "ciste" to nebude.(a generovanie tiez nie je jedina cesta) Ucel vzialenej fasady je ale jasny, OOP krasu je potrebne hladat v nizsich log. vrstvach.

"taka schema sa da docielit"...v .nete (napr. WCF) realne neda a aj docielit aspon primeranu uroven (ani pri message contract) chce mnozstvo kompromisov a mnozstvo hackovania a dorabok = nestoji to za to ani z pohladu investovaneho usilia ani dosiahnutelneho vysledku.

"Ak je to nejaky verejny endpoint, tak samozrejme je ocakavana kvalita schemy vacsia."

co je to "verejny"? Vystaveny do internetu?(intranetu?) Urceny sirokej verejnosti? Skor je otazka, kedy ciste api zmysel nema, kedy neplati elementarna bezpecnostna premisa, ze mam odmietnut spracovanie nevalidneho vstupu tak skoro, ako sa len da. Kedy mi teda nezalezi na "silnom" wsdl? Hobby projekte? mozno. Takych situacii je realne malo, kde by mi nezalezalo na "silnej" validacii alebo jasnosti kontraktu.

"ci v konkrétnom scenary ma taka validacia vobec zmysel, alebo je to len boj s veternymi mlynmi."

sorry, ale cely povodny blog je o tom, ze mam scenar, kedy je validacia potrebna...ze existuju situacie, kedy sa to mozem vykaslat nikto nespochybnuje, len je ich mozno menej, ako si clovek mysli.

A aky kvalitny moze byt ten "swagger", ak nemam dostatocne popisne API ? A cas straveny na dopisovanie romanov je mozno lepsie investovat do popisu contractu v DSL (Domain specific language) aky v tomto zmysle je WSDL/XSD alebo JSON/Schema.

Problem vygenerovat by to asi nebol, otazkou je, ci by to bolo ucelnejsie, ako zacat riesit JSON schemu.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 15. 10. 2017 9:03:47 Liero (anonym)

No napriklad ked riesim komunikaciu medzi dvoma komponentami v tom istom solution, tak veru citatelna schema zmysel velky nema.

A to ci mas popisne api alebo nie, nezalezi od toho ci pises json schemu alebo samotne api. To s tymi romanmi som nepochopil.

"otazkou je, ci by to bolo ucelnejsie" presne to som chcel povedat. Napriklad pri takej SPA appke s WebApi backendom ti je json schema naco?

Jedna vec, co sa mi nepaci na rucnom pisani validacie v json scheme je, ze aj tak sa nevyhnes validacii v kode, lebo vsetko sa to schemy dat neda. Potom mas vsetko v kode a nieco v scheme a trpi maintanability.

Podla mna je radovo jednoduchsie napisat custom generator json alebo wsdl schemy, ako naopak.

Ale uznavam, ze su pripady, kedy by som mozno zacal schemou. Urcite to niesu agilne projekty, kde API a konzument su vlastnene jednym teamom

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 15. 10. 2017 13:32:55 harrison314

Osobne mi pride code first pristup ci uz pri WCF alebo WebApi viac udrzatelnejsi. Plus citatlnost WSDL-ka sa az tak neriesi, klienta vygenerujes, alebo klientom dodas klinetsku kniznicu s rozumnym API.

Len Web Api moze ist aj cez XML, BSON, ProtoBufers,... takze tam by som tiez uprednostnil code first.

Videli ste uz poslednych 5 rokovniekde Web Api na XML-ku?

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 15. 10. 2017 17:42:40 Liero (anonym)

Plus tych specifikacii na popis rest servicov je tolko a menia sa pomerne casto, ze slovo standard sa mi zda prehnane.

Ale musim sa priznat, ze si ma donutil zamysliet sa nad ulohov schem, @T. Ja som tu ulohu chapal doteraz len popisne. Ci ma byt jej ulohou aj validacia, nad tym sa musim este zamysliet.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 17. 10. 2017 13:39:05 Liero (anonym)

@T: No ok, tak teda zacal by som JSON schemou pisat pekny kontrakt. A potom co? Ako naimplementujem samotny service?

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 0:19:08 T

@liero:
"No napriklad ked riesim komunikaciu medzi dvoma komponentami v tom istom solution"

asi v tom istom zmysle, ako nedava zmysel citatelny interface dvoch tried v ramci jedneho projektu. Tvoje metody maju parameter object[]?

"A to ci mas popisne api alebo nie, nezalezi od toho ci pises json schemu alebo samotne api. To s tymi romanmi som nepochopil."

Ja zase nerozumiem tejto Tvojej vete, nedava zmysel. Wsdl ale v troche obmedzenejsom zmysle zmysle aj json schema popisuje api. Roman - ak mam dobru schemu, nepotrebujem citat dokumentaciu vo forme romanu. Ak chces priklad, hned Ti mozem poslat par liniek na ISVS standartizovane schemy.

"Napriklad pri takej SPA appke s WebApi backendom ti je json schema naco?"
to sa ma pyta architekt, ze preco je potrebna silna validacia pri vzdialenej fasade a este vystrcenej do internetu? :-) mas to napisane vyssie, min. kvoly moznosti odmietnut spracovat a komplexne(a hlavne efektivne) staticky validovat vstup skor, ako ho posuniem do spracovania v runtime.

"Jedna vec, co sa mi nepaci na rucnom pisani validacie v json scheme je, ze aj tak sa nevyhnes validacii v kode, lebo vsetko sa to schemy dat neda. Potom mas vsetko v kode a nieco v scheme a trpi maintanability."

A je to prave naopak z hladiska udrzatelnosti. Tu riesis staticku validaciu a vies ju vyriesit komplexne a udrzatelne a v kode riesis kontextovu aka biznis validaciu co je zase ina problematika a iny ucel. (je potrebne to rozvadzat dalej?)

"Podla mna je radovo jednoduchsie napisat custom generator json alebo wsdl schemy, ako naopak."

Ano a preto za 10 rokov neexistuje moznost generovat takyto zazrak pri WCF. Je to zle postavena otazka. Na to aby si takyto schemu vedel vygenerovat by si mysel zaniest okolo kodu Tolko doplnkovych informacii, ze Ti oplati pouzit domenovo specificky jazyk a urobit to priamo v nom. Sme spat pri udrzatelnosti....a produktivite...

Agilne...ach...zase retardacia pojmu...povedzme skor male, jednoduche, hobby etc. projekty...kde na tom nemusi zalezat, ale to som napisal aj ja vyssie....

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 0:31:05 T

@harrison:
"Osobne mi pride code first pristup ci uz pri WCF alebo WebApi viac udrzatelnejsi. Plus citatlnost WSDL-ka sa az tak neriesi, klienta vygenerujes, alebo klientom dodas klinetsku kniznicu s rozumnym API."

Udrzatelnejsi pri rovnakej kvalite/komplexnosti validacie? Asi nie.
Klienta vygenerujes pripadne napises? A obecne a cross platformovo z coho lepsie? Z kvalitnej schemy alebo krivajucej vygenerovanej, ktora nedokaze vyuzit ani vsetky vlastnosti xml? Chlapi typujem, ze ani jeden z Vas sa nezaoberal nikdy kvalitou tej generovanej schemy a nikdy nehladal hranice na ake sa da posunut.

"Videli ste uz poslednych 5 rokovniekde Web Api na XML-ku?"
:-) a co relevatne vyplynie z odpovede na tuto otazku?

"Len Web Api moze ist aj cez XML, BSON, ProtoBufers,... takze tam by som tiez uprednostnil code first."

Ak je scenar podporovat vsetky formaty(zrejme bezny scenar), tak je to specificky scenar, schemy maju zmysel, ale mozno nie schema first pristup (mozno...)

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 0:59:37 T

"Plus tych specifikacii na popis rest servicov je tolko a menia sa pomerne casto, ze slovo standard sa mi zda prehnane."

Preto sa mozno oplati byt tam, kde na tom zalezi konzervativnym a zostat pri xml. Ale zase, lepsi nestandard, ako deravy interface, lepsi jasny kontrakt s jasnou moznostou validacie sprav ako hadaj co zbastim pristup (ala UPVS, cest vynimkam - RFO). Je krasne, ze mi potom vygeneruje v OOP jazyku nieco klienta, ked tam mam a to v lepsom pripade property typu objekt. Zo strany serveru sa dozvies "IvalidOperation"....a dokumentacia zvacsa zodpoveda kvalite kodu, takze tiez nic.

"Ci ma byt jej ulohou aj validacia"
Som rad, ze aspon na nieco su dobre tieto moze litanie...;-) a k comu si dospel s odstupom casu?

"@T: No ok, tak teda zacal by som JSON schemou pisat pekny kontrakt. A potom co? Ako naimplementujem samotny service? "

na to narazam vyssie, ze samostny json nie je ekvivalent wsdl...napr. wadl je, ale neviem aka je podpora v .NET (odata ma csdl a to funguje ale v csdl first som neskusal). Uprimne, toto nemam distatocne prebadane, aby som vedel povedat ci je to dnes a v .net prijemna alebo schodna cesta, tiez si beriem z diskusie podnet.
Btw stale vies aj pri json scheme aspon validovat vstup a vystup klient/server, stale si vies z nej vygenerovat "dto" pre vstupne a vystupne spravy na klientovi aj serveri. A mozno je vyhodne pracovat len s generickou reprezentaciou json struktury na servery, mozno mas na druhej strane nie .net web api ale service napisany v nodejs ....a nic generovat nemusis z pohladu sprav/dto. Toto je jedna zo slabosti oop jazyka, komplexnost, ktora je potrebna na riesenie hierarchickych struktur bez behaviour.


# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 9:43:44 Liero

@T:
ked sa bavime o komunikacii dvoch .NET komponentov v ramci tej istej solution, tak mam na haku ako vyzera WSDL, kedze si proxy klienta generujem, pripadne reusujem triedy. Myslim ze WSDL generator reflektuje aj validacne atributy a aj popisne attributy typu description, takze to co sa mi tu snazis podsunut "pristup hadaj co zbastim" jednoducho nieje pravda.

V pripade WebApi si zase mozem generovat typescriptove (pripadne JSDoc) interfaces, pripadne rovno javascriptove proxies. Nieje zlozite si napisat vlastny taky generator.

Neviem, aky je problem si napisat vlastny generator WSDLka. Ved to je obycajne XML a pokial vies pisat WSDL rucne, tak by si nemal mat ziaden problem. Urcite to je jednoduchsie ako pisat vlastny generator C# proxies cez roslym. Ale isiel som oboma cestami a obe boli schodne.

Moj problem totizto spociva v tom, ze zo schemy sa da lahko generovat client proxy, ale nedokazes vygenerovat server implementaciu, resp interface.

Agilny vyvoj som spominal pretoze agilita znamena schopnost hybat sa rychlo a prisposobovat sa castym zmenam. Pokial pises schemu rucne a potom k nej musis rucne napisat implementaciu tak aby to pasovalo ku scheme, tak to nieje agilny vyvoj ale waterfall, lebo najhrubsim moznym sposobom porusujes DRY, navyse to naznacuje, ze najprv riesis architekturu a potom business value. To bud znamena ze nevies co je to agilny vyvoj, alebo s nim niesi stotozneny (ale nechem flamovat ohladom agile vs waterfall).


Mimochodom, pozeral som asp.net core zdrojaky a validacia schemy by nastala presne na tej istej urovni ako @harrison314 riesenie. V pripade, ze mas obe, tak tesne predtym. Pravdepodobne by sa dala validacia schemy predsunut este skor v pripade potreby, ale to nic nemeni na tom, ze si ju radsej vygenerujem z kodu, ako ju pisat rucne a potom rucne pisat aj implementaciu.

Pokial by som riesil waterfall projekt, kde by som mal system a requirementy podrobne popisane, mozno by som zacal schemou. Tu by to malo zmysel.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 10:29:48 Liero

@T: kazdopadne sa obaja zhodneme, ze popisne API jednoznacne ano.

Jedine na com sa nezhodneme je, ci je lepsie pisat najskor schemu, alebo generovat schemu z kodu.

Tak ako pri pisani schemy musis mysliet na to, co z toho vylezie, tak aj pri pisani kodu musis mysliet na to, aka schema z toho vylezie a zahrnut do kody vsetky info, ktore sa maju objavit v scheme (description, validaciu, response types, atd).

Rozdiel medzi nami vidim len v tom, ze ja radsej napisem vlastny generator kodu, resp schemy, ako by som mal porusovat DRY. V konecnom dosledku sa mi to doteraz vzdy vyplatilo

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 14:08:42 T

@liero:
problem je skor o tom, ci je to efektivne generovat schemu z kodu a aka uroven kvality a za aku cenu sa da dosiahnut....

"Tak ako pri pisani schemy musis mysliet na to, "
ano, len je tu otazna miery, ake kompromisy musis urobit resp. aky je dosiahnutelny vysledok a v tom je prave zasadny rozdiel

...ze ja radsej napisem vlastny generator kodu...vela stastia a zamestnavatela, ktory Ta plati za don quijotske podujatia.(realne si nenapises, takze to zostane derave a skarede ako UPVS)

"ako by som mal porusovat DRY"
aky DRY? Prave naopak, jasna separacia zodpovednosti a ich jasne ohranicenie v ramci logicky vrstiev...co akoze podla teba pri scheme treba pisat 2x?

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 14:55:16 T

"ked sa bavime o komunikacii dvoch .NET komponentov v ramci tej istej solution, tak mam na haku"

to mi je jasne od zaciatku diskusie, ze mas...

"ako vyzera WSDL, kedze si proxy klienta generujem, pripadne reusujem triedy.

rozmer solution je irelevatne, dolezity je scenar pouzitia, na co sluzi dana fasada...ale uz by som sa opakoval...napisal som, kedy je zmysluplne nebyt "striktny"....

"Myslim ze WSDL generator reflektuje"
a to je to, ze si len myslis....

"V pripade WebApi si zase mozem generovat typescriptove (pripadne JSDoc) interfaces, pripadne rovno javascriptove proxies. Nieje zlozite si napisat vlastny taky generator."

Zase si len myslis, lebo mas pred ocami zjavne interface s jednoduchymi strukturami a pravidlami pre staticku (a specialne strukturalnu) validaciu. Skus nieco z realneho zivota...

"Neviem, aky je problem si napisat vlastny generator WSDLka. Ved to je obycajne XML a pokial vies pisat WSDL rucne, tak by si nemal mat ziaden problem. Urcite to je jednoduchsie ako pisat vlastny generator C# proxies cez roslym. Ale isiel som oboma cestami a obe boli schodne."

Technicky ziaden, problem je, ze potrebujes dalsie informacie, aby si vedel vyuzit silu schemy, ktore musi doplnit ako anotacie ku kodu....taky problem a cele podujatie je nezmysel, ked vyskusas opacny pristup (dovody som rozvadzal vyssie)..

"Moj problem totizto spociva v tom, ze zo schemy sa da lahko generovat client proxy, ale nedokazes vygenerovat server implementaciu, resp interface."

No implementaciu pochopitelne nevygenerujem, lebo schema neonsahuje ziadne info o behavior.(to nikto snad neocakava, riesime nieco ine) Ale server side "interface" nadherne vygenerujem (hovorim za WSDL) a je jedno ci java alebo .net.

"Agilny vyvoj som spominal pretoze agilita znamena schopnost hybat sa rychlo a prisposobovat sa castym zmenam."

no zostanme pri tejto definicii

"Pokial pises schemu rucne a potom k nej musis rucne napisat implementaciu"

Zase hrusky a jablka...aku "implementaciu" rucne...pri wsdl generujem aj v .net, pri json based veciach neviem zhodnotit stav v .net

"tak aby to pasovalo ku scheme, tak to nieje agilny vyvoj"

hej hej, porusim najsvatejsie principy programovania (cisty contract) a zbezpecnosti a zacnem mavat agilnostou....super, takuto formu agilneho vyvoja naozaj nemusim(=kowboj style) a som presvedceny, ze ani popularizatori tohoto pristupu...

"ale waterfall, lebo najhrubsim moznym sposobom porusujes DRY"

vysvetelene v prispevku predtym....

"navyse to naznacuje, ze najprv riesis architekturu a potom business value."

:-) hovorim, ze kowboy...

"To bud znamena ze nevies co je to agilny vyvoj, alebo s nim niesi stotozneny (ale nechem flamovat ohladom agile vs waterfall)."

to bude urcite preto, ze neviem....(logika v kontexte toho co pises -> vystupom agilne riadeneho projektu su derave a nejasne interfaces, ak by to bolo inak, uz je to waterfall...)

"Mimochodom, pozeral som asp.net core zdrojaky a validacia schemy by nastala presne na tej istej urovni ako @harrison314 riesenie."

nie nutne ale povedzme, a? Precitaj si reakciu este raz.



"vygenerujem z kodu, ako ju pisat rucne a potom rucne pisat aj implementaciu."

nech sa paci...

"Pokial by som riesil waterfall projekt, kde by som mal system a requirementy podrobne popisane, mozno by som zacal schemou. Tu by to malo zmysel."

nepochopil si...zial....

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 20:08:13 Liero

1. OK, aby sme si to zjednodusili, bavme sa o REST a o WebApi, kedze o tom bol blog a zadefinujme si DRY ako
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". To znamena, ze zmena informacie by mala byt uskutocnena len na jednom mieste a automaticky distribuovana do inych casti systemu, alebo aspon vynutena (kompilatorom, testami).


2. "kowboy styl" - podsuvas mi veci, ktore som nikdy netvrdil, zjavne si ma na niektorych miestach nepochopil. Agilny vyvoj by nemal viest k menej kvalitnemu produktu. Ciel je rovnaky, len cesta k nemu je ina. Ja suhlasim s tvojimi poznamkami ohladom SoC


3. "Zase si len myslis, lebo mas pred ocami zjavne interface s jednoduchymi strukturami a pravidlami pre staticku (a specialne strukturalnu) validaciu. Skus nieco z realneho zivota..."
Mozno, netvrdim ze nie. Skus mi dat ty nieco z realneho zivota..

4. "Ale server side "interface" nadherne vygenerujem"
A tu sa dostavame z mojho hladiska ku korenu problemu. V pripade WebApi vygenerujes server side interface len tazko resp. privelmi by ta to obmzedovalo, vid priklad.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 20. 10. 2017 20:09:25 Liero

ActionResult HelloWorld(int id);

Uz tu si narazil na problem, ze nevies ci vygenerovat response type async Task[ActionResult] alebo len ActionResult, co zavisi od implementacie.

V tomto interface nemas ziadnu informaciu o navratovych hodnotach a http kodoch, dokonca aj o vstupoch (Uri a HTTP metoda) Takze sa musis pozriet na schemu a podla toho to naimplementovat:

[HttpGet("api/HelloWorld"), Authorize]
ActionResult HelloWorld(int id){
if (Find(id) == null) return NotFound();
if (!Valid) return BadRequest(errorJson); //errorJson = ???? vid schema
return Ok("Hello world");
}

Ked zmenis schemu, nevies to automaticky reflektovat tak, aby si neporusil DRY. Ako docielis to, ze ked zmenis schemu, bude zmena vynutena aj v implementacii? Velmi lahko sa stane, ze impementacia bude robit nieco ine ako tvrdi schema a taka schema je horsia ako ziadna.

Inak na tomto priklade vidno, ze v praxi musis casto robit kompromisy medzi SoC a DRY. Pokial robis waterfall tak porusenie DRY z prikladu vyssie nieje az taky problem. Pokial robis Agile, tak budes tu schemu menit niekolkokrat do tyzdna, takze je vacsi doraz na DRY a SoC.

Keby som generoval schemu z kodu, tak sa takmer uplne vyhnem porusovaniu DRY (nie uplne). Viem pouzit napriklad konvencie, typu pridaj do schemy HTTP401 vsade tam, kde je zapnuta autorizacia (zapina sa roznymi sposobmi).

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 21. 10. 2017 11:40:03 T

@liero: nie, nebavme o len o REST a Web API, bavme sa o principe, ktory viem 100% podopriet skusenostou pri SOAP/WSDL ale zial zatial nie pri scheme. (upozornil som na to niekolkokrat a napriek tomu sa pokusat odvadzat pozornost od principov)

1. DRY - do bodky je to dodrzane. A to je len jeden princip. A mozeme napr. diskutovat z hladiska roznych aspektov SoC, bezpecnosti...

2. nepodsuvam, pomenovam to, co popisujes inymi slovami...v com som podla Teba nepochopil?...ak raz mam moznost urobit kvalitnu validaciu, kvalitny popis interface/contact, a existuje na to efektivny prostriedok a Ty ponukas alternativu, ktorej vystupom je nieco o niekolko levelov slabsie...a ospravedlnujes to "agilnostou"...tak aky zaver mam urobit?

3. skusim http://www.opengeospatial.org/standards (vyber si napr. waterml2), http://www.datex2.eu/,
http://www.ehealth.gov.hk/en/information_standards/organisation/index.html... pozri si struktury REGOB/RFO a pod.

4. Uz som o tom pisal...zo json schema vygenerujes strukury bez problemov...to je overene...a na generovanie aj metod potrebujes nieco ine, a napisal som o niektorych moznostiach...nemam overene, neviem posudit, ale ked uz sa o tom bavime, urobit si generator metod z akejkolvek, ked mam vyriesene generovanie struktur je banalne (keby bolo zle) a ma to hranicnu pridanu hodnotu.




# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 21. 10. 2017 12:08:40 T

@liero:
Nepochopil som celkom Tvoju uvahu okolo to prikladu. Ak mam vzdialenu fasadu (hoci cez Web API), vraciam zvacsa typovu spravu...nie ActionResult, nie som cowboy...viem ze vraciam JSON

vykonstruoval si capinu vo vztahu k tomu, co diskutujeme...fakt neviem, ako to suvisi s tym, co pisem. Okrem statickej validacie tam mas este aj kontextovu (Find(id)), autorizaciu..v kode najprv urobis kontextovu validaciu a potom sa snazis strukturalnu? fail

"ked zmenis schemu, nevies to automaticky reflektovat tak, aby si neporusil DRY. Ako docielis to, ze ked zmenis schemu, bude zmena vynutena aj v implementacii? Velmi lahko sa stane, ze impementacia bude robit nieco ine ako tvrdi schema a taka schema je horsia ako ziadna."

nerozumiem...ak zmenim schemu, tak pregenerujem interfaces a strukturu message in/out teda dto. Ak sa zmeni zasadne struktura, kompilator mi vysvieti na cerveno tie casti kodu, ktore su kompatibilne so zmenou, ak som interface rozsil, musim reflektovat v implementacii behavior. Presne to iste, ako ked zmenis priamo strukturu dto Ty. Fakt nechapem o com sa snazis polemizovat.

"Inak na tomto priklade vidno, ze v praxi musis casto robit kompromisy medzi SoC a DRY. Pokial robis waterfall tak porusenie DRY z prikladu vyssie nieje az taky problem. Pokial robis Agile, tak budes tu schemu menit niekolkokrat do tyzdna, takze je vacsi doraz na DRY a SoC."

Pokial robim waterfall ...porusenie DRY je rovnako zle...nechapem, co tu konstruujes..mixujes prog. principy s principmi riadenia...na co je to dobre?
A samotne DRY je vzdy otazka a jedna samostatna tema, ktoru tu fakt nechcem rozvadzat, lebo tu si to vytiahol uplne zbytocne...(vsetok knowledge ohladom strukuralnej validacie mam na jednom mieste - v scheme (DRY) a mam to vhodne odseparovane (SoC)...naopak ziadne hacky, ziadne rozprestieranie know how medzi apektovo riadene casti ovplyvnujuce generovanie schemy a rozne infrastrukturne hacky, aby mi z toho liezla co "najbohatsia" schema.(a ona aj tak nevylezie a vzdas to, ak Ti na tom zalezi, dostanes rozum a zmenis pristup na schema first alebo to nechas derave a budes to pripadne hasit ifmi v kode...)

"Keby som generoval schemu z kodu, tak sa takmer uplne vyhnem porusovaniu DRY (nie uplne). Viem pouzit napriklad konvencie, typu pridaj do schemy HTTP401"

fakt nechapem...staticka validacia mi vyriesi, ci mam spravny vstup pred dalsim spracovanim. Jedine rozumne co mozem vratit v tomto pripade je badrequest ak je schema porusena. Bodka. Potom mozem riesit kontextovu validaciu.
Autentifikacia a Autorizacia je zase iny rozmer, uplne mimo problem statickej validacie. Naco to sem vnasas.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 21. 10. 2017 12:25:15 T

este inak, uz fakt neviem ako to jednoduchsie vysvetlit.... to co tvrdis je analogia(a naozaj celkom dobra) k tomu... ze ak napisem metodu Fire(Employee e) je to podla teba waterfall a nie agile a agile je ked napisem Fire(object e) a vnutry budem robit (v lepsom pripade) if(e is Employee)...a Fire(object e) riesenie je viac DRY ako tu typovost mat zachytenu v definicii triedy alebo interface.
Hladanie Agile vs. Waterfall v oboch pristupoch je irelevatne. Je zjavne, ze DRY je hranicny, SoC dostal na drzku a nevyuzil si prvu a lepsiu moznost na zabranenie poslania nevalidneho vstupu...posunul si staticku validaciu z compile time do runtime. V nasom pripade mame navyse problem, ze nemam rovnako efektivny nastroj v runtime vykonat plnohodnotnu staticku/strukturalnu validaciu.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 21. 10. 2017 15:30:01 Liero

Vidim ze si nepochopil moju uvahu a je to preto ze davas Web Services s WSDL do jedneho vreca s REST services a Swaggerom a na tom to cele pada. Pri WSDL a WCF schema-first moze fungovat celkom dobre to uznavam.

Lenze dobra swagger schema musi obsahovat ovela viac informacii (kedze REST nieje ziaden standard). Jednoducho musis nejako konzumentovi povedat, ze tento service moze vratit 404, hoc to je kontextova validacia. No a co? v scheme to musi byt. Tuto iformaciu nevies preniest do interfacu typu:
string HelloWorld(int id);

Kedze tato informacia musi byt v scheme a nevies ju vygenerovat, musis ju do implementacie vlozit rucne a tym porusujes DRY - nevies zabezpecit konzistenciu medzi schemou a impementaciou..

to ze vracias ActionResult a nie len string je kvoli tomu, ze takto rest services nefunguju. Nevies proste povedat ze input je toto a response je takehoto typu a hotovo.

"metodu Fire(Employee e) je to podla teba waterfall a nie agile a agile je ked napisem Fire(object e)"
to je strasna volovina ktoru som nikdy netvrdil

"Fire(object e) riesenie je viac DRY ako tu typovost mat zachytenu v definicii triedy alebo interface."
to je dalsia volovina ktoru som nikdy netvrdil

To ze navratova hodnota je genericky ActionResult je dane vlastnostami frameworku, ktory ale len mapuje povahu rest services.


"Autentifikacia a Autorizacia je zase iny rozmer, uplne mimo problem statickej validacie, naco to sem vnasas"
Ja to sem nevnasam, to sem patri. Ty sam si si obmedzil schemu len na staticku validaciu a to je zle. Schema v pripade REST Servicov musi obsahovat informaciu o tom, ze dany services moze vratit 401, alebo 403, lebo to je expected response

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 21. 10. 2017 17:27:09 Liero

Mimochodom, code-first implementacia takeho api by vyzerala zhruba takto:

[HttpResponse(200, typeof(string)]
[HttpResponse(404)]
[HttpResponse(400, typeof(ValidationError)]
[Authorize("MyAuthorizationPolicy")]
[HttpGet("api/HelloWorld/{id}"), Description("..")]
public IActionResult HelloWorld(int id)
{
....
return Ok("Hello world");
}

V implementacii mam vsetky informacie potrebne pre schemu, ale naopak neviem ako by to mohlo fungovat.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 23. 10. 2017 19:34:02 T (anonym)

@liero:

Ak to pri WSDL moze fungovat, tak to moze fungovat aj pri WADL, CSDL oDATA (s JSON Schema). Jednoduche.
obavam sa, ze pochopil, odvadzas zbytocne pozornost mimo temu na mozne a pestre (a aj pochybne) pouzivanie HTTP status kodov.

OPAKUJEM, riesime staticku validaciu message in / out, nie generovanie dokumentacie, nie popis spravania sa a mapovania na http error kodov, ktore mozes dostat aj pri volani SOAP sluzby a je na Tebe do akej miery ich budes vyuzivat.(lebo liero vybral jeden sposob, ako je to najlepsie, lebo sa mu to prave hodi, aby vykonstruoval komplikaciu)

Spracovanie nevalidneho vstupu odmietnem s 400 statusom v produkcii, kedze client si ma ako zvalidovat u seba spravu (v debugu mu mozem zobrazit detaily). Rozhodne sa nebudem zaoberat nejakym "ValidationError" v kode, kde z kontextu ani nie je jasne, ci riesi staticku alebo(aj) kontextovu validaciu.

200 - je "expected response"...toto riesim, a 200 je aj ked request neprejde kontextovou/biznis validaciou. Je to nieco, co ma user vidiet, presne naopak ako pri statickej validacii. Ocakavany vstup, ocakavany tok programu.

"Schema v pripade REST Servicov musi obsahovat informaciu o tom, ze dany services moze vratit 401, alebo 403, lebo to je expected response "

Schema spravy musi obsahovat? Naozaj? A ako si toto cudo(reflektovanie http status kodov riesil v xsd (scheme) pri SOAP?

"DRY" - uz s tym naozaj prestan, reakcia na clientovi na nejake statusy zo vzdialenej fasady (ifovanie), kde si mozes chciet vygenerovat nejaku kostru clienta, je podla Teba zmysluplnym predmetom uvah o DRY? Nezmysel.

"to ze vracias ActionResult a nie len string je kvoli tomu, ze takto rest services nefunguju. Nevies proste povedat ze input je toto a response je takehoto typu a hotovo."

Iste ze to viem vracat len string, len keby si tolko nekonstruoval.(to, ze Ty mas potrebu znasilnovat http statusy na rozne a nesurode ucely, co si pri SOAP zrejme nemal, ja nemozem...) Vymyslas taketo komplikacie miesto toho, aby sme temu uzatvorili. Aj ked budes pouzivat http statusy na potrebe a zmysluplnosti mat schemu a validovat minimalne in a out spravy (200, typeof(MessageOut)] nic nemeni.

"To ze navratova hodnota je genericky ActionResult"

Iste ze nemusi, ani mi to neskusaj dokazovat a vrat si WhatEver a uvidis, ze to zafunguje.(a keby to technicky mozne pri WebApi nebolo, akoze je, princip to nespochybnuje, spochybnilo by to len zvoleny fmwk)

"To ze navratova hodnota je genericky ActionResult je dane vlastnostami frameworku, ktory ale len mapuje povahu rest services."

REST...RESTful....teraz mi tu dufam nejdes otlkat o hlavu, ze cez HTTP/JSON ma zmysel riesit len CRUD scenare, aby Ti lepsie sedelo praktizovane znasilnovanie HTTP statusov? (co pri urcitych situaciach moze mat vyhody, ktore su pomerne zname, ale nie pri "tradicnom" komplexnom (integracnom API). Ale aj tak plati, ze min. pri 200 si mas validaovat staticky najlepsie ako sa da a umoznit to aj clientovi.

"Ja to sem nevnasam, to sem patri. Ty sam si si obmedzil schemu len na staticku validaciu a to je zle."

Ano, ja som sa obmedzil na staticku validaciu, lebo o tom sme diskutovali. Auth/Author je uplne iny aspekt, presne tak, ako pri SOAP.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 23. 10. 2017 20:46:14 harrison314

"REST...RESTful....teraz mi tu dufam nejdes otlkat o hlavu, ze cez HTTP/JSON ma zmysel riesit len CRUD scenare, aby Ti lepsie sedelo praktizovane znasilnovanie HTTP statusov?"
Ale ja povazujem za znasilennie, ak sa REST pouziva na nieco ine ako CRUD. Preto ma POST, GET, PUT, DELETE,...

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 23. 10. 2017 21:06:00 liero

@T: Ja odvadzam pozornost mimo temu? skoda s tebou vobec diskutovat

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 23. 10. 2017 21:19:13 liero

Bavime sa o webapi a ty sem tahas WSDL a ja odvadzam pozornost.

Ja ukazem realny swagger priklad, ty sem tahas WADL (mrtvy standard, ktory ani nikdy standardizovany nebol). OData je protokol sam o sebe, preto nepotrebujes popisovat response kody, navyse sam by si to nerobil schema first. ALE BLOG NEBOL O ODATA. A ja tu konstruujem priklady?

Bavili sme sa o tom, ze pisat schemu rucne pre webapi je neudrzatelne, lebo webapi z toho nevies vygenerovat (co je k veci) ale ty si stale zijes vo svojom svete. Cakal by som od teba trochu viac. Co uz..

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 24. 10. 2017 9:57:11 T (anonym)

@Harrison:
"Ale ja povazujem za znasilennie, ak sa REST pouziva na nieco ine ako CRUD. Preto ma POST, GET, PUT, DELETE,... "
a co ine to je, vsetky styry veci zodpovedaju CRUDu...pri komplexnom API s domenovou logikou je mapovanie na CRUD velmi pochybne, najjednoduchsie je to vidiet na DELETE...ked sa casto mapuje zneplatnenie, vyradenie. Potobne aj pri ostatnych.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 24. 10. 2017 16:06:37 T (anonym)

@liero: Ja som otvoril otazku schema first - (a ten princip je jasny a neustale ho spochybnujes nejakym nepochopenim/ohybanim DRY, Agile, naposledy HTTP statusov a pod), ktory je rovnaky tak pri webapi ako soap, ano, stale sem tahas implementacne detaily pri webapi, naco som Ti napisal, ze nemam technicky prejdene v .NET aby som Ti povedal - "takto". WADL spominam zamerne, je to ekvivalent WSDL, podobny rozsah informacii je aj pri odata.(pouzitelne obe pre schema first)

Swagger ....diskusia je o schema first pristupe...tu som otvoril ja v kontexte blogu a Ty si oponoval, tak riesme tuto temu

"Cakal by som od teba trochu viac"
ale ale...mne by uplne stacilo, keby si nebol jesitny.
Ano, aj ja by som od seba cakal viac, ze si najdem cas a ukazem ako to najlepsie implementovat pri WebApi, ale bohuzial mam aktualne ine priority.

Ak cakas, ze Ti dam za pravdu(Dry,Agile a ja neviem co este) pri hentych konstrukciach, tak tazko. Vnasat sem kadeco miesto toho, aby si sa poriadne zamyslel na tym principom(chvilu to tak vyzeralo) a pripadne pri web api hladal cestu ako sa da, nie ako sa neda.

# RE: Zabezpečenie vstupov ASP.NET MVC aplikácie 27. 10. 2017 13:31:46 T (anonym)

swagger vyzera byt nakoniec najdostupnejsia cesta pre schema first, vacsinu json schema keywordov podporujee. Ak bude cas vyskusam na niecom realnom.

https://github.com/RSuter/NSwag/wiki/SwaggerToCSharpControllerGenerator

Pridať reakciu

Titulok:
Meno:
Url:
Koľko je 22 + 4?
(ochrana proti spamu)
Komentár:

Najaktívnejší užívatelia
1. 37750 b. photo vlko
2. 21315 b. photo T
3. 15955 b. photo spigi
4. 15450 b. photo Anonymous
5. 11120 b. photo dudok
6. 9355 b. photo Liero
7. 6885 b. photo siro
8. 6245 b. photo slavof
9. 5355 b. photo duracellko
10. 4445 b. photo xxxmatko