Post

Visualizzazione dei post da 2014

Authentication vs Authorization

Ancora una volta mi trovo in mezzo ad una diatriba; se vogliamo un dilemma semantico, o semplicemente due concetti che vengono erroneamente usati in maniera interscambiabile nel comune linguaggio tecnico. Mi sto riferendo alle due parole Authentication e Authorization che da molti anni calcano la scena IT per dei sistemi più o meno complessi, web e desktop. La sicurezza in questi ultimi tempi - come mai in passato - ha assunto un ruolo non solo importante, ma fondamentale per ogni architettura che si rispetti; tanto, che non solo è basilare creare e nutrire il dato, ma preservarlo incontaminato, sicuro, protetto proporzionalmente al suo valore. E' così che, ogni due/tre anni nascono nuovi tecniche per difendere l'informazione, che vanno a braccetto con altrettante tecniche di "hacking" - perdonatemi il termine non propriamente preciso - per forzare o addirittura distruggere le informazioni stesse. Ma oggi non sono qui a parlare relativamente a specifiche di sic

Progettazione: da un approccio tradizionale ad uno più modulare

Ormai è parecchio che non bloggo più: vuoi per scadenze importanti e molto (troppo) ravvicinate, vuoi per necessità di dedicare più tempo alla famiglia. Resta il fatto: sono "assente" da qualche mese, ma non sono stato certo con le mani in mano ;)... Da parecchio tempo sto cercando di dare un'impronta differente ai progetti a cui lavoro. Che siano di piccole dimensioni oppure più corposi, la necessità è quella di avere sistemi che siano facilmente manutenibili, efficienti e il più possibile flessibili; senza però impattare sulle prime due caratteristiche desiderate. Il "mondo a servizi" disaccoppia sempre di più la user interface dagli strati applicativi dedicati alla persistenza e all'elaborazione. La tendenza, anche dei grandi competitors presenti sul mercato, è quella di realizzare piattaforme "internet-based" che siano autoconsistenti ed agnostiche; in pratica capaci di erogare un servizio e una funzione, indipendentemente da quelli che saran

Throttling monitor con ASP.NET MVC

Il "throttling" spiegato in due parole? Capacità di un sistema informativo di tracciare l'occorrenza delle chiamate ad un particolare risorsa (o una funzione) disponibile nel sistema stesso; identificando il chiamante ed, eventualmente, imponendo delle limitazione all'utilizzo della risorsa in funzione di alcune policy prestabilite. A cosa serve e come è possibile sfruttarlo? Il campo di applicabilità è certamente molto vasto, ma è una tecnica maggiormente utilizzata per la sicurezza dei sistemi, e la misurazione della responsività degli stessi a fronte di un elevato numero di richieste. Per esempio è possibile monitorare il numero di invocazioni ad un particolare metodo esposto da un vostro servizio web, e la frequenza con cui avvengono. Questo, per prevenire attacchi esterni, provenienti da malintenzionati che vogliono mettere in crisi il servizio che offrite. Ultimamente mi è capitato di dover realizzare una serie di servizi - esposti pubblicamente su rete inte

ASP.NET: WebForms vs MVC

Quanto Microsoft, nel lontano 2009, ha rilasciato ASP.NET MVC, mi sono chiesto il motivo per cui è stato scelto di mettere a disposizione un framework web che affiancasse ASP.NET WebForms. Ad una prima occhiata non sono riuscito a vedere i vantaggi della nuova tecnologia, rispetto ad un'altra, solida, ben collaudata e diffusa come WebForms. E' da sottolineare che il grande merito di quest'ultima, all'inizio del nuovo millennio, è stato avvicinare una massa di sviluppatori desktop (la maggior parte dei quali legati al buon vecchio Visual Basic 6.0), al mondo web. Il paradigma di programmazione che veniva proposto - nella sua semplicità concettuale - era geniale: simulare il modello "ad eventi" (tipico dei desktop, appunto) applicato al web. La magia realizzata da "postback" e "viewstate" ha quindi permesso, solo con l'introduzione di qualche nuovo concetto, di aumentare esponenzialmente il numero di web-developers Microsoft, qu

ActionFilter: tracciamento di request e response di un metodo MVC

Immagine
Sviluppando una SPA (Single Page Application) ci si trova spesso a doversi confrontare con problemi di serializzazione e deserializzazione di dati in formato JSON (Javascript Object Notation), da e verso il server remoto. La tecnologia che ho scelto per il mio server-side backend è ASP.NET MVC: a mio parare la scelta più naturale e sensata per uno sviluppatore che ha un forte background .NET. In fase di sviluppo, una delle attività che maggiormente fanno perdere tempo, è proprio comprendere perchè questo o quel metodo non risponde correttamente: errore nel passaggio dei parametri, problemi di formattazione, variabili e fields passati con la denominazione errata, etc. E la problematica si ingigantisce quando ci si trova a sviluppare il backend per dei colleghi che si occuperanno solo della parte client dell'applicativo: due mondi completamente isolati, dove la firma dei metodi server rappresenta l'unico "contratto" a garanzia delle due parti. Ma i contratti e gli