Done in 60 Minutes: Building a Custom DotNetNuke Membership Provider
Prior to Microsoft’s release of the .NET 2.0 Framework, DotNetNuke handled authentication, authorization, and membership deep inside the core code, through its own custom implementation. While this functionality worked just fine, as far as the Framework’s membership requirements were concerned, it did not take into account use cases where the developer wished to replace the default implementation with external membership data stores through other APIs; at least not without forking the code and therefore making it more difficult to keep up with future framework upgrades.
One of ASP.NET 2.0’s many new features, the Provider Model, enabled DotNetNuke to abstract several of its custom base implementations, such as Data, Logging, Navigation, Scheduling, Membership, Profile, and more, thus giving more options to those wishing to integrate DotNetNuke with enterprise applications.
In this Wrox Blox, I will discuss and demonstrate how DotNetNuke takes advantage of ASP.NET 2.0’s Provider Model and how it implements the ASP.NET Membership Provider. Replacing the custom membership model did not come with a shortage of challenges. I will talk about the compromises and the creative thinking that went into accomplishing this task.
The Provider Model
With the release of the .NET 2.0 Framework, Microsoft unveiled a new pattern designed to provide a simple way to extend base functionality. The .NET Provider Model was born.
Since ...
