Costruzione di aree protette

Se tutto sommato negli altri scenari cambiano gli oggetti, ma la tipologia di lavoro è simile, per quanto possibile, nel caso della costruzione di aree protette non c'è davvero quasi niente in comune.

Con Classic ASP il tipico esempio di autenticazione prevede una form che convalidi i dati in un database e poi si occupi di creare un cookie o più spesso una variabile di sessione.

Con questo snippet in VBS, che deve essere ripetuto (anche con un include) in ogni singola pagina da proteggere, in genere si verifica che un utente sia loggato, altrimenti lo si rimanda alla pagina iniziale del sito:

Con ASP.NET 2.0, invece, si utilizza la cosiddetta FormsAuthentication, che l'utilizzo delle Membership APIs rende di uso davvero banale.

Questo articolo contiene una trattazione esaustiva dell'argomento e vi consente di inquadrare meglio la questione, ma ancora una volta l'approccio è totalmente dichiarativo.

Si prende il web.config e si aggiunge qualcosa come:

L'approccio è nettamente differente e consente di non dover toccare la pagina (o un gruppo di pagine) perché il ? nell'attributo users della chiave deny equivale a negare l'accesso a tutti gli utenti che non siano effettivamente autenticati. L'articolo appena menzionato contiene un esempio che potete scaricare per provare quanto sia potente questo approccio, dato che è possibile specificare anche una directory, per non essere costretti a dover proteggere ogni singolo file.

E' proprio in questo semplice esempio che la potenza dell'approccio di ASP.NET 2.0 viene tutto fuori, perché questa funzionalità è basata sui provider, ovvero sulla possibilità di demandare l'effettiva memorizzazione ed il recupero dei dati ad un componente esterno, che può essere sostituito in qualsiasi momento senza toccare il codice, consentendoci di passare da Access a SQL Server, senza modificare nient'altro che la definizione del provider nel web.config.

Come personalizzare una pagina in base all'utente

Sebbene Session o cookie siano ancora supportati da ASP.NET, la scelta migliore in questo ambiente è quella di utilizzare le Profile APIs che, analogamente a quanto offerto dalle Membership APIs, consentono di utilizzare un approccio totalmente dichiarativo alla definizione del profilo dell'utente.

Per profilo si intendono tutte quelle informazioni che non sono strettamente legate alla fase di autenticazione dell'utente, come nome, sesso o data di nascita.

Ancora una volta, con ASP la scelta obbligatoria era quella di utilizzare una variabile Session (o un cookie), ma comunque quella di lasciare del tutto alla memoria dello sviluppatore il nome della chiave, con risultati che spesso erano viziati da errori di battitura.

Con ASP.NET, invece, il profilo viene definito ancora una volta direttamente nel web.config:

Nell'esempio aggiungiamo tre proprietà e ne definiamo anche la tipologia. In questo modo abbiamo un accesso strongly typed alle proprietà, senza problemi di conversione, ma soprattutto grazie all'Intellisense offerto da VS 2005, ci viene mostrato in automatico il nome della proprietà, senza l'eventualità di dimenticanze o errori, perché l'accesso è fatto in un modo simile al seguente:

In questo caso dunque non c'è nient'altro da fare, perché è il provider su cui si basano le Profile APIs a fare il resto.

E tutto sommato creare un profilo (c'è anche il supporto per i profili anonimi e per la conversione da anonimo a loggato) è semplice, bastano queste semplici righe di codice:

E può essere fatto, ovviamente, anche prelevando i dati da una form.

Ancora una volta, la differenza è netta, marcata e la comodità di un approccio del genere davvero tanta.

Dove trovo provider aggiuntivi?

La domanda a questo punto è ovvia: come sfrutto questo sistema con il numero maggiore possibile di database?

Ecco una lista di provider da aggiungere, perché di default ci sono solo per SQL Server e ActiveDirectory:

• Access
• MySQL
• SQLLite 3.0
• Oracle (dentro l'applicazione di esempio PetShop)

Se ciò che state facendo è migrare un'applicazione che ha già la sua struttura, che volete mantenere, la scelta migliore è di crearne uno custom, seguendo le indicazioni di questo articolo.

Ricapitolando...

Che tra ASP ed ASP.NET 2.0 non ci sia paragone è ovvio. Si potrebbe al limite discutere su quale tra i due ambienti vi faccia essere più produttivi, ma probabilmente la cosa potrebbe dipendere dalla mancanza di dimestichezza con ciò che vi offre ASP.NET 2.0.
In questa prima parte dell'articolo abbiamo analizzato le caratteristiche (e quindi le relative differenze) delle funzionalità più diffuse, ma il discorso non si ferma certo qui.
Nella prossima parte continueremo ad analizzare le restanti funzionalità, anche se quanto trattato contiene già diversi spunti interessanti per il vostro lavoro.

Contenuti dell'articolo

• Pagina 1
  • Prima di cominciare: gli strumenti
  • Il rendering cambia forma
  • Il modello dichiarativo di ASP.NET
• Pagina 2
  • Le differenze nell'accesso ai dati
• Pagina 3
  • Costruzione di aree protette
  • Come personalizzare una pagina in base all'utente
  • Dove trovo provider aggiuntivi?
  • Ricapitolando...

• Galleria fotografica dinamica con ASP.NET AJAX
• Usare Search come un servizio nei tuoi siti e nei tuoi client
• Mappe nel tuo sito con Virtual Earth
• Integrare Windows Live ID, Contacts e Presence API nelle tue applicazioni
• Introduzione ai cloud based service con Windows Live Services
• Realizzare un custom extender AJAX con ASP.NET 3.5
• Tracciare le modifiche ai dati e allineare i datawarehouse con il Change Data Capture in SQL Server 2008
• Le nuove caratteristiche di IIS 7.0 per sviluppatori e sistemisti