Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Writing A Custom Membership Provider for your ASP.NET 2.0 Web Site

If you have an ASP.NET Web site that stores any registration or log in information for your users, you probably know that the Membership provider in ASP.NET 2.0 uses a SQL Server Express 2005 database. But what if you want to use something else? This article will show you to use your own data source for storing membership information.


advertisement
ne feature introduced in ASP.NET 2.0 is the use of the "provider model" to provide maximum flexibility and extensibility to your Web applications. Using the provider model, developers can easily extend the capabilities provided by the ASP.NET 2.0 runtime, in many different ways. For example, you can extend the provider model to store the membership information for your Web site users in a custom data store, rather than the default SQL Server Express 2005 database.

To understand how the provider model works, consider the new Login controls in ASP.NET 2.0. The relationships between the Login controls and their underlying APIs are shown in Figure 1.

Figure 1. The Membership Provider Model: Everything involved in the use of the ASP.NET provider model is shown.

At the top level are the various Login controls themselves. Underlying the controls are the various APIs that perform the work needed to implement the functions of the various controls. The Membership class takes care of tasks such as adding and deleting users, while the MembershipUser class is responsible for managing users' information, such as passwords, password questions, etc. The Membership and the MembershipUser classes use one of the membership providers to save user information to data stores.



In Visual Studio 2005 (beta 2 as at this writing), ASP.NET 2.0 ships with one default membership provider—SQL Express Membership Provider. The role of the provider is to act as a bridge between the membership APIs and the membership data, so that developers need not be concerned with the details of data storage and retrieval. Think of the membership provider as a middle-man in charge of all communications between the APIs and the data.

However, if the provider supplied with ASP.NET 2.0 does not meet your needs, you can write your own custom provider. In this article, I will show you how to build a custom membership provider that uses an Access database (rather than the default SQL Express 2005 database) to store users' information. You can then adapt the concepts covered in this article to use any data source (such as Oracle database, XML files, or even plain text files) you want for your membership provider.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap