Soci (Soczó Zsolt) szakmai blogja

2015.04.16.

Mire használja az MVC a machinekeyt?

Filed under: .NET,ASP.NET,mvc,Szakmai élet — Soczó Zsolt @ 22:51

A source alapján nekem úgy tűnik csak az AntiForgeryTokenhez. Van még szerintetek valami más szerepe is (nem webformsról beszélünk).

Tovább nézve látom az ASP.NET Identity is használja, a Tokeneket védeni.

2014.10.09.

Ha egy MVC site nem ad vissza semmit

Filed under: .NET,.NET 4,.NET 4.5,ASP.NET,mvc,Szakmai élet — Soczó Zsolt @ 18:34

De hibát se, akkor lehet egyszerűen nincs minden IIS modul feltelepítve, ami kell hozzá.

2014.04.10.

Overposting vagy Mass Assignment támadás ASP.NET MVC-ben

Filed under: .NET,ASP.NET,mvc,Szakmai élet — Soczó Zsolt @ 09:25

Nagyon hasznos a binder az MVC-ben, nem kell kézzel kiszedegetni a form értékeket és átmásolni a modellbe. De ha a modell több property-t tartalmaz mint amit a html formba kigenerálunk, akkor ki vagyunk téve egy támadásnak. Ugyanis minden további nélkül be lehet rakni a post kérésbe olyan mezőket is, amelyek nincsenek a formon, de benne vannak a modellben, így alapban, ha nem korlátozzuk le a binder szépen feltölti a modellt a fake bepostázott értékekkel is. Ez durva secu támadásokra ad lehetőséget.
A kivédésére itt bemutatnak sokféle megoldást. A legjobb szerintem az utolsó, amikor tényleg az adott view részére hozunk létre egy specifikus modellt, nem pedig a bindert próbáljuk meg lebeszélni a felesleges adatmásolásokról.

Ps. ma végzek a jelentkezési lappal mvc-ben a TDD tanfolyamra, nem véletlenül szól mvc-ról a post. :)

2014.02.10.

Rétegek közötti kommunikáció

Filed under: .NET,.NET 4,.NET 4.5,ASP.NET,C#,mvc,Szakmai élet — Soczó Zsolt @ 23:27

Tegyük fel emailt akarok küldeni egy weboldalról, amiben linkekeket kell elhelyezni, amik hivatkoznak a weboldal urljeire.
Az email generálás a business logic jellegű komponensekben van. Ezeknek nem illik kinyúlkálni HttpContextekbe meg mindenféle webes cuccokba, mert ők nem webes cuccok. De ebben az esetben mégis csak fel kéne dinamikusan deríteni, hol fut a webapp, mert urleket kell generálni.

Ha kézzel passzolom át a szükséges infót, így néz ki a hívási lánc:

ArticleController.ArticleEdit => (innentől BBL, nem web) IArticleManager.UpdateArticle => INotificationManager.ArticleModified => INotificationFormatter.SendNotification

Na, a NotificationFormatternek már tudni kell urleket gyártani, a felette futó website intrinsic property-jei alapján.
Ezt kézzel átpasszolni a teljes láncon ronda. Mi jöhet még szóba? Statikus változók, amit a webapp indulásakor pl. a global.asaxben feltöltök, és a BLL-ben kiolvasom? Nem tetszik, de egyszerű. Utálom a statikusokat, szétborítanak minden tesztet.
Létrehozni egy IWebEnvironment interfészt, amit a tesztekben fake-elek, élőben pedig szintén a web indulásakor betárazok a DI containerbe? Kicsit körmönfont, de ez egy fokkal jobban tetszik.
Ötlet?

2014.01.30.

MVC project indulás lassú

Filed under: .NET,.NET 4,.NET 4.5,ASP.NET,mvc,Szakmai élet — Soczó Zsolt @ 17:36

Normális, hogy minden egyes fordítás után fél percet kell várni, mire az mvc projekt elindul? Vagy csak nálam ilyen tetű lassú? Nem debuggerben, nem symbol issue, csak simán ránézve böngészőből. Cassinivel és iissel is. Hm?

Powered by WordPress