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.
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.
De hibát se, akkor lehet egyszerűen nincs minden IIS modul feltelepítve, ami kell hozzá.
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. :)
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?
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?