2

May

Windows Azure Lab – Le membership e Windows Azure Storage

Il Membership Framework di ASP.NET, noto anche ai molti come “le membership”, sono da sempre un argomento molto interessante per chi vuole implementare un sistema di autenticazione e autorizzazione efficente per la propria applicazione ASP.NET, senza scrivere una riga di codice. Nell’era in cui è PROIBITO reinventare la ruota, questo approccio è decisamente condivisibile.

Ci sono alcuni contesti in cui questo approccio però non può essere adottato e in tal caso è perlomeno suggerito di utilizzare lo stesso un sistema a Membership, implementando però il proprio provider come meglio si creda o si debba fare. Nel tutorial di oggi vediamo come utilizzare il meccanismo di membership “plain”, cioè normale, di ASP.NET su Azure (avrei voluto dire semplice, ma le M sono tutt’altro che una infrastruttura banale).

imageIntanto partiamo dall’inizio e impediamo l’accesso non autenticato ad un certo path nella nostra virtual folder (come a sinistra). Poi l’abitudine ci può dire di andare a configurare la sezione apposita del Web.config con il provider per Azure: giusto! Ma prima dobbiamo importare la librerie, al momento in namespace “Samples” (il che ci suggerisce che non sia definitiva) all’interno delle reference del progetto.

La liberia è AspProviders, il cui namespace esteso è: Microsoft.Samples.ServiceHosting.AspProviders.

Ora è il caso di decidere se andare direttamente su un Azure Storage reale o utilizzare quello di sviluppo; per la configurazione di entrambi si rimanda alla lettura di uno dei precedenti post. A questo punto l’importante è che la stringa di connessione si chiami DataConnectiongString (per utilizzare le impostazioni di default del provider), oppure venga poi opportunamente passato il parametro al tag del provider, nella sezione membership.

A questo punto arriva una configurazione a cui siamo abbastanza abituati:

image

E già con solo questo possiamo utilizzare tutto il Login Framework di ASP.NET senza problemi e senza intervenire nel codice. Tipicamente possiamo addirittura switchare la vecchia membership su ASP.NET con la nuova senza intervenire nella pagine che utilizzano i controlli ASP.NET relativi al login.

Ma manca una cosa: la gestione dei ruoli.

Siccome vogliamo tutti poter chiamare la IsInRole(“”) o semplicimente annotare i metodi protetti con gli attributi di autorizzazione, è necessario fare il setup del role provider:

image

(Opzionale) la persistenza della sessione

Oltre che ad essere (dal titolo del paragrafo) una sezione opzionale, salvare la sessione su Azure Storage non è neanche una delle cose più geniali che potremmo fare. Infatti benchè siamo sicuri che il provider sia costruito efficentemente, salvare uno stato potenzialmente molto volatile (in termini di tempo) in uno storage basato su chiamate rest su http è un approccio lento. Già la soluzione di persistere la sessione su SQL Server fa sempre arricciare il naso ai molti (ma è un passo necessario in caso di web farm), in questo caso le performance (senza obbligo di dimostrazione) si complicano.

A titolo esemplificativo, ecco come si dovrebbe configurare il tutto per permetterlo:

image

by Roberto Freato on 5/2/2011
Post archive