3 pagine in totale: <<Indietro 1 2 [3]
Creazione del provider
Come abbiamo visto in precedenza, per specificare il provider per l'applicazione utilizziamo il web.config. Grazie ad esso il runtime sa quale classe utilizzare per la gestione della Membership (Dependency Injection). Nel caso del provider personalizzato AzMembershipProvider, è prima di tutto necessario ereditare la classe dal tipo System.Web.Security.MembershipProvider.
Ecco la prima parte della nostra classe.
namespace System.Web.Security
{
using ...
public class AzMembershipProvider : MembershipProvider
{
string _url;
string _name;
public override void Initialize(string name, NameValueCollection config)
{
if (config == null)
{
throw new ArgumentNullException("config");
}
if ((name == null) || (name.Length == 0))
{
name = "AzProvider";
}
_name = name;
if (config["url"] == null)
throw new ArgumentNullException("Missing 'url' parameter!");
else
_url = config["url"];
base.Initialize(name, config);
}
...
}
}
Come detto, la classe AzMembershipProvider eredita dalla classe MembershipUser e opera un override del metodo Initialize della classe base e di tutte le funzioni di interesse. Nel nostro caso ci limitiamo ad inserire unicamente le funzioni per la creazione di un nuovo utente, per il controllo della sua esistenza più altre d'obbligo.
public override bool ValidateUser(string name, string password)
{
try
{
localhost.Validate v = new localhost.Validate();
return v.ValidateUser(name, password);
}
catch
{
return false;
}
}
public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
{
localhost.Validate v = new localhost.Validate();
if (v.CreateUser(username, password, email))
{
status = MembershipCreateStatus.Success;
return new MembershipUser(
_name, // provider name
username, // nome utente
"xxx", // provider user key
email, // email
passwordQuestion, // domanda
string.Empty, // commento
true, // abilitato
false, // bloccato
DateTime.MinValue, // data di creazione
DateTime.MinValue, // data di login
DateTime.MinValue, // data dell'ultima pagina visualizzata
DateTime.MinValue, // data dell'ultimo cambio di password
DateTime.MinValue); // data dell'ultimo blocco avvenuto per quell'utente
}
else
{
status = MembershipCreateStatus.UserRejected;
return null;
}
}
public override bool RequiresQuestionAndAnswer
{
get { return false; }
}
public override string Name
{
get { return _name; }
}
Entrambi i metodi implementati richiamano il web service. Il metodo ValidateUser viene chiamato sul primo server per la verifica di username e password con il ritorno di un valore booleano (true: i dati sono corretti; false: i dati sono errati). Per CreateUser facciamo un passo indietro visto che, come detto in precedenza, non possiamo serializzare in SOAP la classe MembershipUser. Per questo motivo, dopo aver verificato che l'utente sia stato creato correttamente, istanziamo la classe MembershipUser specificando alcuni dati fittizi, dato che, per esempio, la data di creazione dell'account o la data del suo ultimo accesso nel nostro caso non ci interessano.
È bene ricordare che pressoché tutti i metodi di MembershipUser sono dichiarati come abstract. Per evitare errori di compilazione, facciamo l'override dei membri astratti con una implementazione fittizia, sollevando per ciascuno di essi l'eccezione NotImplementedException.
public override bool EnablePasswordRetrieval
{
get { throw new global::System.NotImplementedException(); }
}
public override bool EnablePasswordReset
{
get { throw new global::System.NotImplementedException(); }
}
E con questo abbiamo concluso... Le due applicazioni sono in grado di condividere i dati dell'utenza in modo trasparente e senza aver complicato il codice con personalizzazioni estreme.
Allegato
Gli esempi trattati in questo articolo sono disponibili nel file ZIP allegato. Il file in questione include le due applicazioni già configurate per il funzionamento corretto. E' sufficiente creare due directory virtuali in IIS di nome "mem1" e "mem2" e il gioco è fatto. Inizialmente non sono presenti utenti all'interno del database, ma è sufficiente crearne uno direttamente dalla pagina web e verificare che si possa autenticare da entrambe le applicazioni. Buon divertimento!
Conclusioni
Il modello dei provider è ampiamente utilizzato nella nuova versione del Framework. Il vantaggio nell'uso dei provider è la flessibilità ed estendibilità che è garantita dalla possibilità di iniettare le dipendenze tra i tipi a runtime, definendo nella configurazione quale tipologia di implementazione concreta utilizzare. Come abbiamo visto in questo articolo, questo discorso vale anche per la Membership: possiamo definire i nostri meccanismi di autenticazione custom e renderli intercambiabili tra loro.
3 pagine in totale: <<Indietro 1 2 [3]
Attenzione: Questo articolo contiene un allegato
Contenuti dell'articolo
- 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
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Utilità
Stampa 
Download
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!