Demo dello SMAU disponibili per il download.
Da ieri è disponibile il download della demo utilizzata durante lo streaming su IE9 e HTML5 allo SMAU.
Colgo l’occasione per “pubblicizzare” il progetto che ho recentemente aperto su codeplex, dove potete trovare tutte le mie demo e gli esempi che da oggi in poi utilizzerò per i vari posts.
Buon Download.
P.S.: per la demo dello storage, se fatta con IE9, richiede di “hostare” i files tramite un web server (IIS/Cassini per il mondo Microsoft) altrimenti non funziona J
IE9 + HTML5 Live Streaming
Giovedì 21 ottobre avrò l’onore ed il piacere di partecipare come speaker per Microsoft Italia allo streaming sulla presentazione di IE9.
La mia sessione sarà basata sulle novità (lato sviluppo) dell’html5, quindi canvas, semantics tags, storage, video, etc.
Ovviamente non potete perderlo! Maggiori informazioni sullo streaming e registrazione sono disponibili qui. Chi invece partecipa allo SMAU può venire direttamente a trovarci 
.
Ciauz
NuPack, ASP.NET MVC 3 beta 1 e WebMatrix beta 2
Chi come me usa Twitter sicuramente ieri avrà notato un alternarsi di “retweet” riguardanti alcune novità di Microsoft; nello specifico è stata rilasciata la prima beta di ASP.NET MVC 3, la beta 2 di WebMatrix, ed è stato presentato NuPack, il tutto a completare un importante annuncio avvenuto nei giorni precedenti riguardante alcuni plugin per jQuery realizzati da Microsoft stessa.
Devo dire che la presentazione di NuPack mi ha lasciato un po’ spiazzato; sinceramente non me l’aspettavo, ma personalmente ritengo che l’idea sia grandiosa.
NuPack:
NuPack è un add-on per Visual Studio 2010 che facilita l’utente nell’integrazione delle principali librerie OpenSource, all’interno dei propri progetti. Per intenderci, grazie a pochi click possiamo aggiungere NHibernate, Castle, Log4Net, etc alle nostre applicazioni.
Di seguito un video dimostrativo del suo utilizzo:
L’unico neo al momento è che le librerie presenti non sono molto aggiornate, ma non credo che passerà molto tempo prima che questo avverrà.
ASP.NET MVC 3 Beta:
Come sempre nessuno stravolgimento, ma tante piccole novità che lo vanno a completare sempre di più:
- Migliorato il supporto a Razor, mancano ancora l’intellisense ed alcune integrazioni con Visual Studio, (come la voce “vai al controller” dal menu contestuale), ma alla creazione del progetto è possibile scegliere il ViewEngine da utilizzare;
- Nuovi Html Helpers (strongly type ovviamente) , come Chart, Crypto, WebGrid, WebImage e WebMail;
- Dependency Injection migliorata rispetto alla preview;
- Unobtrusive JavaScript and HTML 5: ora Ajax e la validazione fanno utilizzo dell’approccio unobtrusive JavaScript di default;
- Intregrazione con NuPack, come MVC Contrib, jQuery, etc;
WebMatrix Beta 2:
Minor numero di nuove features/improvements per questa release rispetto a MVC, ma in ogni caso parliamo di novità di un certo rilievo:
- La creazione delle pagine ora gode del supporto di Razor al pari di MVC3: di fatto ora è possibile creare pagine sia con C# che con VB, sfruttando a pieno il nuovo ViewEngine di casa MS;
- Nuovi template che comprendono anche funzionalità riguardanti HTML5 e CSS3;
- Una serie di toolkit installabili tramite il NuPack, che comprendono Analytics, Facebook, GamerCard, Gravatar, LinkShare, Captcha, Twitter, etc;
Ed ora la parte più interessante, i downloads:
NuPack è disponibile a questo indirizzo http://nupack.codeplex.com/, ASP.NET MVC 3 Beta lo trovate qui e WebMatrix Beta 2 qui.
Buon Download.
MVP Award Again!
Venerdì ho ricevuto la mail di conferma da quel pazzo di Alead, che mi comunicava il rinnovo dell’award (in MS ci sono tanti “pazzi” :D).
In ogni caso devo dire che l’emozione è al pari della prima nomina, e spero di poter migliorare contenuti, sia in qualità sia quantità, anche se quest’ultimo periodo non rispetta molto queste parole.
Un super ringraziamento a tutti voi che mi seguite ed i complimenti ai nuovi ed ai rinnovati compagni di avventure.
Ciauz
Scoperta una vulnerabilità su ASP.NET
Tramite il blog di Scott Guthrie, è stata presentata una soluzione temporanea ad un recente problema di vulnerabilità scoperto nel Framework ASP.NET, a partire dalla versione 1.1 fino ad arrivare alla recente 4.0.
La vulnerabilità è piuttosto grave in quanto, in determinate condizioni di configurazione, un utente malintenzionato potrebbe scaricare files contenenti informazioni riservate, come il web.config.
Prima di allarmarsi è necessario capire che il problema è facilmente risolvibile: è possibile proteggere le proprie applicazioni da questo tipo di attacco senza dover ricompilare e/o deployare il sito, ma semplicemente caricando una pagina sul server e modificando il file di configurazione.
Come prima cosa è necessario creare una semplice pagina .aspx “user friendly” contente un messaggio che comunica all’utente il verificarsi di un errore all’interno dell’applicazione, ed inserire il seguente codice direttamente nella pagina stessa:
//VB.NET
<%@ Page Language="VB" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
Sub Page_Load()
Dim delay As Byte() = New Byte(0) {}
Dim prng As RandomNumberGenerator = New RNGCryptoServiceProvider()
prng.GetBytes(delay)
Thread.Sleep(CType(delay(0), Integer))
Dim disposable As IDisposable = TryCast(prng, IDisposable)
If Not disposable Is Nothing Then
disposable.Dispose()
End If
End Sub
</script>
<html>
<head runat="server">
<title>Error</title>
</head>
<body>
<div>
Si è verificato un errore
</div>
</body>
</html>
//C#
<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
void Page_Load() {
byte[] delay = new byte[1];
RandomNumberGenerator prng = new RNGCryptoServiceProvider();
prng.GetBytes(delay);
Thread.Sleep((int)delay[0]);
IDisposable disposable = prng as IDisposable;
if (disposable != null) { disposable.Dispose(); }
}
</script>
<html>
<head runat="server">
<title>Error</title>
</head>
<body>
<div>
Si è verificato un errore
</div>
</body>
</html>
A questo punto non ci resta che registrare la pagina appena creata all’interno del file di configurazione ed il gioco è fatto.
<configuration>
<system.web>
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
</system.web>
</configuration>
Per chi fosse interessato alla vulnerabilità, consiglio la lettura del post ufficiale di Scott Guthrie con tutta la spiegazione del problema che trovate qui.
Introduzione a ConfORM
Posted by imperugo in Nhibernate on Monday 20 September 2010 at 9:45 AM
Chi mi segue su Twitter sicuramente saprà che ultimamente mi sono messo a “giocare” un po’ con ConfORM, e, nello specifico, ho deciso di rimpiazzare FluentNHibernate in Dexter, per far strada al Framework prodotto da Fabio Maulo.
Per chi non lo conoscesse, ConfORM è un Framework che facilità incredibilmente tutta la parte di mapping del nostro dominio - quando si utilizza NHibernate per la persistenza - cambiando totalmente l’approccio; ma andiamo per gradi.
Oggigiorno esistono diversi modi di scrivere il mapping per NHibernate, partendo dal classico e mai datato XML, fino ad arrivare a Framework più recenti come FluntNHibernate, Ddl2Hbm, VisualNHibernate, etc.
Purtroppo questi framework hanno lo stesso approccio, obbligandoci a specificare la corrispondenza di ogni singola property di ciascuna classe di dominio verso il database.
Non conosco i vostri gusti relativamente alla scrittura di codice, ma personalmente ritengo molto noiosa e ripetitiva la fase di stesura del mapping, motivo per cui ConfORM la vince su tutti gli altri.
L’approccio di ConfORM.
Come già accennato ConfORM ha preso totalmente un’altra strada; di fatto inizialmente può lasciare l’utente un po’ spiazzato, ma quando si è capito il funzionamento è sicuramente un viaggio di sola andata, in quanto induce ad abbandonare totalmente il mapping “tradizionale”.
Di fatto quello che è necessario fare è “istruire” ConfORM con le nostre “regole” di sviluppo e di nomenclatura e specificare solo le eventuali eccezioni, lasciando a lui il compito di generare e gestire tutta la fase di mapping.
Per capire meglio il vantaggio, il grafico seguente mostra il Dominio di Dexter che in precedenza era mappato con FluentNHibernate in 27 classi differenti ed ora è mappato in poco più di 20 righe di mapping
Maggior Produttività e controllo.
Un altro vantaggio sicuramente interessante è l’aumento di produttività: possiamo aggiungere e togliere classi al nostro dominio senza toccare il mapping, a condizione che queste rispettino le regole stabilite precedentemente.
Quest’aspetto è sicuramente molto interessante perché ci permette di modificare il dominio senza preoccuparci di dover aggiornare il mapping, e riduce il rischio di introdurre errori dovuti ai continui cambiamenti.
Un altro aspetto che adoro è la rigidità che si può introdurre nel lavoro in team, in quanto se qualche sviluppatore non rispetta le regole di mapping prestabilite è obbligato ad andare a dichiarare l’eccezione manualmente e quindi il cambiamento è facilmente identificabile; un esempio banale potrebbe essere la nomenclatura delle tabelle: si è stabilito che sul database esse debbano chiamarsi con il nome della classe di dominio ma al plurare e, se un dev vuol chiamare la tabella in maniera differente è obbligato a gestire lo special case a mano e specificarlo nel mapping.
Performance:
L’utilizzo di ConfORM porta anche vantaggi prestazionali alla nostra applicazione in quanto, a differenza di tutti gli altri Framework di mapping, genera direttamente le classi necessarie a NHibernate per il suo utilizzo, saltando così tutta la fase di parsing del file xml contenente il mapping.
Ovviamente quest’aumento di performance è beneficiabile solo in fase di startup ed è sicuramente apprezzabile quando si ha a che fare con domini piuttosto corposi.
Per capire meglio il funzionamento di ConfORM rispetto al classico mapping o ad altri Framework, riporto qui un grafico “rubato” dal blog di Fabio che spiega perfettamente il perché dell’aumento di performances.
Conclusioni:
Ovviamente seguiranno altri post che mostreranno la parte più tecnica di ConfORM, ma per chi non volesse aspettare riporto alcuni link utili:
Enjoy your mapping.
Generazione di dati fake durante la scrittura di test.
Spessissimo, quando mi trovo a dover scrivere dei test, ho la necessità di creare delle istanze di classi contenenti dei dati finti, in modo da verificarne il corretto funzionamento.
Di fatto, se proviamo ad immaginare di dover testare un metodo ForEach per una classe IEnumerable(vedi qui), sicuramente nel test dobbiamo creare una lista contente gli elementi da iterare.
Anche se semplice, la creazione di un set di informazioni finte, anche tramite classi “helper”, può risultare una fase noiosa e ripetitiva.
Grazie ad un consiglio di Fabio ho provato questo framework, che ci aiuta tantissimo nella creazione di liste - ma anche di singole istanze - con dati fake.
Il funzionamento è piuttosto banale ed intuitivo: di fatto si ha una composizione fluent che ci permette di coprire i principali scenari.
Per capire il suo potenziale provate ad immaginare di dover creare una lista di 10 elementi…con NBuilder si può ottenere lo stesso risultato con una sola riga di codice! J
var posts = Builder<Post>.CreateListOfSize(10).Build();
Ovviamente si possono specificare anche criteri un po’ più “strong”, forzando il valore di una specifica proprietà o addirittura alternando un valore all’interno della lista.
var posts = Builder<Post>.CreateListOfSize(10)
.WhereAll()
.Have(p => p.Username = "imperugo")
.Build();
Un'altra feature che trovo interessantissima è la possibilità di persistere l’oggetto su di un nostro repository, quindi invocare un metodo passando il dato creato. Chi scrive integration test troverà sicuramente questa feature molto vantaggiosa.
//Definisco il servizio di persistenza da invocare BuilderSetup.SetCreatePeristenceMethod<Post> (postService.SaveOrUpdate); //Persisto l'oggetto fake Builder<Post>.CreateNew().Persist();
Ovviamente il framework offre numerosissime altre features, che trovate qui.
Direi un must.
Enjoy it.
Implementare OpenSearch sul proprio sito
Nel weekend scorso ho deciso di implementare l’OpenSearch all’interno del mio blog in modo da offrire un servizio in più ed imparare una cosa nuova.
In pratica lo scopo era di creare un provider di ricerca per i principali browser di navigazione come Internet Explorer, Firefox e Chrome.
L’implementazione è piuttosto banale: basta creare un HttpHandler - o un file statico nel caso in cui le informazioni non necessitino di una gestione dinamica - contenente un set d’informazioni in formato XML, aggiungere il link a tale risorsa nell’header della pagina, ed il gioco è fatto; il browser penserà poi a recuperare in automatico le informazioni e a “proporvi” il provider di ricerca da aggiungere.
Il codice dell’HttpHandler è veramente banale e lo potete vedere qui di seguito:
public class OpenSearchHandler : HttpHandlerBase
{
private readonly ISiteConfigurationService siteConfigurationService;
private readonly IUrlBuilderService urlBuilder;
public OpenSearchHandler ()
{
siteConfigurationService = IoC.Resolve<ISiteConfigurationService> ();
urlBuilder = IoC.Resolve<IUrlBuilderService> ();
}
public OpenSearchHandler ( ISiteConfigurationService siteConfigurationService , IUrlBuilderService urlBuilder )
{
this.siteConfigurationService = siteConfigurationService;
this.urlBuilder = urlBuilder;
}
public override void ProcessRequest ( HttpContextBase context )
{
SiteConfigurationDTO configuration = siteConfigurationService.GetConfiguration ();
StringBuilder sb = new StringBuilder ( "<OpenSearchDescription xmlns=\"http://a9.com/-/spec/opensearch/1.1/\"> " );
sb.AppendFormat ( "<ShortName>{0}</ShortName>" , configuration.BlogName );
sb.AppendFormat ( "<Description>{0}</Description>" , configuration.SeoConfiguration.DefaultDescription );
sb.AppendFormat ( "<Image height=\"16\" width=\"16\" type=\"image/vnd.microsoft.icon\">{0}{1}</Image>" , urlBuilder.SiteWithHttp () , "Images/favicon.ico" );
sb.AppendFormat("<Url type=\"text/html\" template=\"{0}blog/search?q={1}\" /> ", urlBuilder.SiteWithHttp(), "{searchTerms}");
sb.AppendFormat("<Url type=\"application/rss+xml\" template=\"{0}blog/search?q={1}\" /> ", urlBuilder.SiteWithHttp(), "{searchTerms}");
sb.Append ( "</OpenSearchDescription>" );
context.Response.ContentEncoding = Encoding.UTF8;
AddHeaders ( "text/xml" , 30 , sb.GetHashCode () );
context.Response.Write ( sb.ToString () );
}
}
Mentre per quanto riguarda l’header della pagina html, è sufficiente inserire il seguente markup html:
<link type="application/opensearchdescription+xml" rel="search" title="Il blog di ugo lattanzi" href="/opensearch.axd"/>
A questo punto il risultato dovrebbe essere più o meno quello riportato negli screenshot seguenti:
Internet Explorer:
FireFox:
Nota: Chi fosse interessato può esporre anche il suggest nella ricerca, restituendo un set di informazioni in formato json (vedi qui).
Ciauz
Compilare le applicazioni a 64Bit
Ultimamente mi è capitato uno strano errore che mi ha fatto “scervellare” (passatemi il termine) per individuarne la causa, poi la soluzione si è presentata davanti agli occhi ed era più semplice di quel che pensavo (anche se devo ammettere che il messaggio di errore non era di aiuto); ma partiamo dall’inizio.
Un paio di settimane fa ho sviluppato un plugin per Dexter che non fa altro che mostrare informazioni provenienti da vari feeds rss; nel mio caso specifico sono feeds RSS dei principali social network a cui partecipo, ed il mio scopo era di creare una pagina che li aggregasse tutti insieme in modo da riassumere le mie ultime attività (per chi fosse interessato al funzionamento può vedere il risultato finale qui).
I plugin in Dexter non sono altro che delle semplici librerie caricate automaticamente a runtime ed aggiunte all’application domain principale (ancora per poco ); al contrario degli altri plugin, come il like di facebook, questo non ne voleva sapere di partire, restituendo sempre il seguente errore:
Server Error in '/' Application.
Could not load file or assembly 'Dexter.Plugins.LifeStream' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: Could not load file or assembly 'Dexter.Plugins.LifeStream' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Source Error:An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Assembly Load Trace: The following information can be helpful to determine why the assembly 'Dexter.Plugins.LifeStream' could not be loaded.
Ora io ero certo che l’applicazione si trovasse nel path corretto e che tutto funzionasse a norma; di fatto in locale il plugin sembrava perfetto, eppure doveva esserci un fattore che ne impediva il funzionamento nel server di produzione.
Indagando un po’ a fondo e cercando errori simili in rete sono risalito al problema, scoprendo che il tutto era dovuto alla compilazione della libreria in questione che non era a 64bit come richiesto dal server di produzione.
Purtroppo non so per quale motivo, ma il nuovo progetto del plugin aggiunto a Visual Studio aveva la compilazione abilitata solo per i 32bit e non “Any CPU” come mi aspettavo, e l’application pool in produzione era configurato per eseguire soltanto codice compilato per i 64bit e quindi si rifiutava (giustamente) di caricare l’assembly, bloccando il flusso corretto di funzionamento dell’applicativo.
Al contrario nella mia macchina di sviluppo era tutto funzionante perché nella configurazione di IIS era stata impostata l’opzione “Enable 32-bit Application” negli “Advanced Settings” dell’application pool, come mostrato dallo screenshot seguente.
Come potete vedere il problema è piuttosto banale e facilmente risolvibile se non per il “non bel” messaggio di notifica.
64-bit Rulez!
Gestire HttpRequestValidationException in ASP.NET MVC
Chi lavora con le applicazioni web si sarà sicuramente imbattuto nell’eccezione HttpRequestValidationException scatenata dall’engine di ASP.NET quando un client cerca di effettuare il submit di informazioni potenzialmente pericolose, aka codice html, verso il server.
Personalmente ritengo questa una comodissima feature in quanto ci consente di “alleggerire” la nostra applicazione nell’analisi dei dati in ingresso e demandare il tutto ad ASP.NET; al contrario, se si vuole gestire questa casistica secondo dei propri requirements, è possibile disattivarla e prendersi carico e responsabilità del fatto che ciò che arriverà dal client non è stato validato da nessuno.
Dando per assodato che, dal mio punto di vista, questa funzione dovrebbe rimanere abilitata, quello che vorrei specificare in questo post è come mostrare all’utente un messaggio “friendly” che lo invita ad inserire del plaintext nel campo di input. L’idea è nata analizzando il log del mio blog, in cui ho trovato una miriade di tentativi di commenti che cercavano di inserire link (praticamente tutto spam), ma senza successo grazie a questo blocco.
Questo è possibile in diversi modi, come con l’utilizzo di httpmodule, applicationError, etc., ma in applicazioni MVC preferisco utilizzare il meno possibile HttpModule (vuoi perchè in IntegratedMode passa veramente di tutto) e gestire la cosa dal controller.
In Dexter ho un ControllerBase da cui ereditano tutti i controller, dove, oltre ad esporre delle ActionResult custom, ho la gestione dei log per ciò che riguarda la parte di MVC, in soldoni ho l’override del metodo OnException dove butto dentro la mia logica di logging, etc.
Quando una qualsiasi eccezione riguardante una richiesta MVC viene sollevata dal framework, si può essere certi che verrà intercettata e verrà invocato quel metodo, permettendoci di gestirla a nostro piacimento.
protected override void OnException(ExceptionContext filterContext)
{
HttpException httpException = filterContext.Exception as HttpException;
if (httpException is HttpRequestValidationException)
{
Logger.Info ( httpException.Message , httpException );
var currentUrl = filterContext.RequestContext.HttpContext.Request.Url.AbsolutePath;
filterContext.ExceptionHandled = true;
filterContext.Result = RedirectToAction("HttpRequestValidation", "Errors", new
{
aspxerrorpath = currentUrl
});
} else if (httpException != null && httpException.GetHttpCode() == 404)
Logger.Info(httpException.Message, httpException);
else if (filterContext.Exception is HttpAntiForgeryException)
Logger.Info(filterContext.Exception.Message, filterContext.Exception);
else
Logger.Error("Generic Exception", filterContext.Exception);
}
Come potete vedere non è nulla di fantascientifico ed è più o meno quello che si andrebbe a fare con un’applicazione WebForm classica, fatta eccezione per l’utilizzo della proprietà ExceptionHandled, che notifica a MVC che siamo noi a prenderci in carico il Result da quel momento in poi, e di fatto subito dopo si va ad effettuare un redirect.
Il risultato è questo.
Archive