Správičky 2 797 Blogy 945 Fórum 18 537

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 - 779 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: 190, Príspevkov v blogu: 0, Bodov: 1070
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....

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. 21310 b. photo T
3. 15955 b. photo spigi
4. 15450 b. photo Anonymous
5. 11110 b. photo dudok
6. 9295 b. photo Liero
7. 6885 b. photo siro
8. 6245 b. photo slavof
9. 5355 b. photo duracellko
10. 4445 b. photo xxxmatko