You can also download this information via this PDF file.

Discuss this topic on our forums

Overview

DotNetNuke uses the "Providers" pattern extensively in order for developers to change functionality without having to modify the Core code base. Using well known interfaces and/or abstract classes developers are able to "plug-in" new behavior for their implementation and ultimately can be used by custom module(s). For the core code executing against these classes, it is none the wiser as to the "how" or "where" the custom implementation is running or handling requests, if at all. DNN Membership and Role providers are examples of this pattern.

This document was developed using DotNetNuke 4.3.4, but should work for other versions of DotNetNuke 4.3.*

Intent

This document intent is to provide DNN developers a "starting point" source of information to replacing the out of the box ASPNetMembersShipProvder with a custom provider. Included are also some important considerations that will need to be made before you begin development and how you can get started programming your implementation.

Considerations

If you are considering replacing the Membership functionality you should ask yourself these questions:

• Why am I replacing the membership (authentication) in the first place? The answer should be that I already have an existing data store with a user base and I want to validate user from my DNN site against.
• Can I achieve what I need by adding on to the existing functionality provided or am I replacing the user's data store and the validation process entirely? In some cases, it may make more sense to sync the users and passwords into the default ASPNET tables. This could be desirable if the long term strategy is to phase out the other system entirely.
• Does the other system that I plan on replacing provide enough functionality to satisfy the abstract MembershipProvider that DNN uses? Important! You must look through the list of methods/properties that this abstract class contains and be sure that you can provide answers to those questions as needed in order for your implementation to work seamlessly.
• Can I retrieve a decrypted password from the new data store? It is important to understand how you will handle password resets, forgot password and random password generation before you start. Otherwise you will not be able to provide this functionality in your custom provider.

Understanding all the Pieces

Before you begin, it is very important to understand all the pieces within DNN. What are the membership and role providers? The first step is to locate the abstract classes (or concrete classes) that your implementation will be extending and examine all the signatures and their behavior. During this process you should be asking the question "how will my version answer these questions?". Below is an overview of the Membership and Roles implementation that should provide a good starting point for your project.

Membership

The membership provider provides the membership functions to allow a user access to your DNN site. i.e. Validating username/password. The default install for DNN uses ASPNetMembersShip provider. This provider class does not extend the Microsoft SqlMemberShipProvider class as with the previous versions of DNN. This is a very important difference. The ASPNetMembership class extends a DNN class DotNetNuke.Security.Membership.MembershipProvider which has a lot of the same signatures as the built in System.Web.Security.SqlMembershipProvider class. The ASPNetMembersShip class essentially forwards every request to the built in implementation from Microsoft to perform reads/writes to the ASPNET_* tab