Brian Mishler on .Net

How to implement a Custom Provider in a WinForms Application

Brian Mishler — Sun, 04 Feb 2007 03:51:37 GMT

Since we always see the “Provider Model” used in the context of Asp.Net applications (Membership Provider, Roles Provider, Etc.) we often think of this as something that is available only in the Asp.Net world. It was recently mentioned to me that there are no good source code examples for custom providers in the Winforms space and that the Asp.Net examples utilize the System.Web.Configuration.ProvidersHelper class to instantiate the provider.

While there are several other blogs that talk about bits and pieces of this subject, I thought I might create a start-to-finish Windows Forms Application that illustrates how one can effectively use the provider model. I wrote the solution in Vb.Net and have included it in the attached zip file.

Advance disclaimer: When I started into this, I thought to myself “of course you can do this without any of the System.Web classes” and, in fact, you totally can with just a little bit more work than I put into this. I cheated a bit by dropping in a reference to System.Web in order to gain access to System.Web.Configuration.ProvidersHelper to deserialize my provider elements, but this is only because I am lazy and was copying code from another project. That class is doing nothing fancier than standard deserialization of XML into an instance of a class. Besides: Who says you can’t reference System.web from a Winforms app?

So, consider this scenario:

You develop a Winforms Application and have some standard functionality, business rules, etc. For example, your application calls a method that returns a standard report. Knowing that down the road, each one of your customers is going to want to change the way that report works, you decide to build the reporting class using the provider model. This way, you can later build a custom DLL that implements the same interface as the reporting class (but with unique functionality) and can be installed by simply copying the DLL to the application folder and then making a change to the application configuration file (myapp.exe.config.) Every customer can get his/her own unique reporting DLL and the main application never needs to be modified.

In a nutshell, this is how you do it for an existing class:

Step 1: Create a base “mustInherit” class which has the methods (but no code implementation) of your current class. In the COM world, this is analogous to an Interface. Now, modify your class to inherit from this new base class.

Step 2: Create classes that will be used to deserialize information in your app.exe.config. These will derive from classes in the System.Configuration namespace and will include one for your configuration section, one for a collection of provider settings and one for the provider settings itself. Doing this will result in a strongly typed system for referring to your list of configured providers and their respective settings at runtime.

Step 3: Modify your main application so that rather than instantiating that existing class as you might have done before, you instead ask the configuration manager to use the information in yourapp.exe.config to load up your custom section and give you back an instance of the provider which has been dubbed as “the one to use.”

To illustrate this process, I have whipped up a very simple base provider “MyProviderBase” that exposes a single method: “GetProviderSpecificMessage()”. I then have two separate implementations: “MyFirstProvider” and “MySecondProvider”, each of which handles GetProviderSpecificMessage() in its own way. (While all of this is pretty basic stuff, the interesting part is where you enable selective usage of one or the other implementations through settings in the configuration file.) A tiny winform application, consisting of a button on a form does nothing more than load the appropriate provider and call its “GetProviderSpecificMessage” method.

With the configuration file set up to use the first provider, the output is as shown in the following message box. (Notice that defaultProvider=”MyFirstProvider” in the application configuration file shown below.)

Big note: In your solution, the file called app.config will be deployed as yourapplicationname.exe.config when you build. When you distribute the application, just drop this config file into the same folder as the exe.

Now, do nothing more than change the configuration file to set defaultProvider=”MySecondProvider” and you get a totally different result when you run the program.

For a top-down look at the implementation, I will first talk about the winForm app (which I wrote last) and then about the provider implementation. As you can see, the solution is very basic.

The WinForm Application:

Start a new Winform project and drop in a button control. In the button’s click event, get the implemented provider, call its GetProviderSpecificMessage method, and display its result in a MessageBox. Here is the code:

Imports QualityData

Imports System.Configuration

Imports System.Web.Configuration

Public Class Form1

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Dim provider As MyProviderBase = GetProvider()

If Not IsNothing(provider) Then MsgBox(provider.GetProviderSpecificMessage)

End Sub

Private Function GetProvider() As MyProviderBase

' get reference to configuration section for our provider

Dim section As MyProviderSection = CType(ConfigurationManager.GetSection("myProvider"), MyProviderSection)

If Not IsNothing(section) Then

' load registered providers and get reference to default provider

Dim providers As New MyProviderCollection

System.Web.Configuration.ProvidersHelper.InstantiateProviders(section.Providers, providers, GetType(MyProviderBase))

Return CType(providers(section.DefaultProvider), MyProviderBase)

Else

Return Nothing

End If

End Function

End Class

Another big note: This is the place where I used the shared ProvidersHelper.InstantiateProviders method in the System.Web.Configuration namespace to walk through my section and instantiate each of the listed providers. I don’t know why Microsoft did not put the ProvidersHelper class into the System.Configuration assembly but it is really not such a big deal to have to get to it in System.Web. If I get around to it, I might go for extra credit and write my own InstantiateProviders method by enumerating the elements and instantiating each provider based on its type.

The Application .config file

Here is the application’s config file (mine is called WinformProviderSample.exe.config.)

<?xml version="1.0" encoding="utf-8" ?>

</configSections>

<!-- Here are one or more providers, each defined by its type "Class Name, DLL Name"

and each with settings. Within the class, MyProviderSection, these get loaded into

and are accessed by "Providers" property -->

<add name="MyFirstProvider"

type="QualityData.MyFirstProvider,MyProvider"

TheCustomSetting="This is the first provider setting value in app.config" />

<add name="MySecondProvider"

type="QualityData.MySecondProvider,MyProvider"

TheCustomSetting="This is the second provider's setting value in app.config"

TheExtraMessage="..And here is some extra information to configure the second provider!!!!" />

</providers>

</myProvider>

</configuration>

Notice that I have listed two providers: MyFirstProvider and MySecondProvider. As illustrated, the configuration file is set up to use the second.

Each of the provider elements has a name as well as a type attribute. The latter is structured as “ClassName,Assembly” where “ClassName” (QualityData.MyFirstProvider) is the fully qualified class name including the namespace and “Assembly” is the name of the assembly (MyProvider.dll) without the “.dll”. You can tell that both classes are contained in the same assembly in this example.

Notice also that each provider section can have its own set of attributes. In “MySecondProvider”, for example, the attribute “TheExtraMessage” is optionally used to pass in extra configuration information that may be used by this particular implementation.

Hopefully you will agree that this is a fairly convenient and simple deployment story.

The Provider Classes

Now let’s talk about the provider. The project: MyProvider consists of several classes which I put into a single file for brevity. Here is the code in its entirety:

Imports System.Configuration

Imports system.Configuration.Provider

Namespace QualityData

' This is the base class that defines the required methods of any implementation

Public MustInherit Class MyProviderBase : Inherits ProviderBase

' For simplicity, we will have a single method that gets implemented

' differently based on the chosen provider.

Public MustOverride Function GetProviderSpecificMessage() As String

End Class

' The following two classes are "providers" that implement the base in different ways

' Ordinarily, each of these two classes would be in its own DLL since much of the idea of the

' Provider model is to be able to ship new behavior that can be "dropped in" without replacing

' the rest of the application

Public Class myFirstProvider : Inherits MyProviderBase

Private _myUniqueMessage As String

Public Overrides Sub Initialize(ByVal name As String, ByVal config As System.Collections.Specialized.NameValueCollection)

' Override the method of Configuration.Provider.ProviderBase

' default provider name if missing

If String.IsNullOrEmpty(name) Then name = "MyFirstProvider"

' initialize base and get custom settings

If Not IsNothing(config) Then

MyBase.Initialize(name, config)

' get the setting from config file

_myUniqueMessage = config("TheCustomSetting")

End If

' default setting to something uniquely from this provider

If String.IsNullOrEmpty(_myUniqueMessage) Then _myUniqueMessage = "FIRST PROVIDER WAS HERE!!"

End Sub

Public Overrides Function GetProviderSpecificMessage() As String

' return string that has provider-specific prefix as well as data from config

Return "The First Provider says: " & _myUniqueMessage

End Function

End Class

Public Class mySecondProvider : Inherits MyProviderBase

Private _myUniqueMessage As String

Private _anExtraMessage As String

Public Overrides Sub Initialize(ByVal name As String, ByVal config As System.Collections.Specialized.NameValueCollection)

' Override the method of Configuration.Provider.ProviderBase

' default provider name if missing

If String.IsNullOrEmpty(name) Then name = "MySecondProvider"

' initialize base and get custom settings

If Not IsNothing(config) Then

MyBase.Initialize(name, config)

' get the setting from config file

_myUniqueMessage = config("TheCustomSetting")

' this second provider can have its own extra settings

_anExtraMessage = config("TheExtraMessage")

End If

' default setting to something uniquely from this provider

If String.IsNullOrEmpty(_myUniqueMessage) Then _myUniqueMessage = "#2 PROVIDER WAS HERE!!"

End Sub

Public Overrides Function GetProviderSpecificMessage() As String

' build up a return string that is specialized for this provider

Dim sb As New System.Text.StringBuilder

sb.Append("The Second provider does it differently: ")

sb.Append(_myUniqueMessage)

If Not String.IsNullOrEmpty(_anExtraMessage) Then sb.Append(" " & _anExtraMessage)

Return sb.ToString

End Function

End Class

' We will be swapping out providers through simple changes to the app's .config file

' This can go quite deep to give you a lot more control but here are the basics:

' 1) MyProviderSection, defines a configuration section for app.config

' 2) MyProviderCollection, defines the collection of providers listed within our section of .config

' This class lets the configuration manager create a strongly-typed instance of our

' section based on the information listed in the application's .config file.

Public Class MyProviderSection : Inherits ConfigurationSection

<ConfigurationProperty("providers")> _

Public ReadOnly Property Providers() As ProviderSettingsCollection

Get

Return CType(Me("providers"), ProviderSettingsCollection)

End Get

End Property

<StringValidator(minLength:=1), ConfigurationProperty("defaultProvider", defaultvalue:="MyFirstProvider")> _

Public Property DefaultProvider() As String

Get

Return CStr(Me("defaultProvider"))

End Get

Set(ByVal value As String)

Me("defaultProvider") = value

End Set

End Property

End Class

' This class lets the configuration manager create a strongly-typed collection of

' providers based on the information listed within the section for our custom provider.

Public Class MyProviderCollection : Inherits ProviderCollection

Public ReadOnly Property MyProviderBase(ByVal name As String) As MyProviderBase

Get

Dim o As Object = Me(name)

If o IsNot Nothing Then Return CType(o, MyProviderBase) Else Return Nothing

End Get

End Property

Public Overrides Sub Add(ByVal provider As System.Configuration.Provider.ProviderBase)

' check for valid type (ie, make sure the listed provider inherits from our base)

If IsNothing(provider) Then Throw New ArgumentNullException("provider")

If Not TypeOf provider Is MyProviderBase Then Throw New ArgumentException("Invalid provider type", "provider")

' add

MyBase.Add(provider)

End Sub

End Class

End Namespace

Most of this is self explanatory and hopefully the code comments will help to make it clear. Notice that we have a (mustinherit) base class that inherits System.Configuration.Provider.ProviderBase and defines the single required method “GetProviderSpecificMessage”. We have two classes that inherit from that base and override the Initialize method to load in the configuration goodies that are passed in as a NameValueCollection.

We also have a custom ConfigurationSection class that minimally extends its base by setting the defaultProvider’s defaultValue property to “MyFirstProvider”.

Finally, we implement “MyProviderCollection” which inherits from System.Configuration.ProviderCollection and contains a list of providers that derive from our custom provider base (MyProviderBase.)

Download, run and extend the source in the project and let me know if any of this is useful to you.

Brian Mishler

WinformProviderSample.zip (99.86 KB)

How to determine where a provider is configured

Brian Mishler — Thu, 27 Apr 2006 12:28:52 GMT

In an Asp.Net application, if you check the properties of the various Asp.Net providers at runtime, you will get a value that is something of a hybrid between default and custom settings. Similarly, if you check a property such as ConfigurationManager.ConnectionStrings(“LocalSqlServer”).ConnectionString, you will get a value that may originate in web.config or result from a default setting.

Why is this?

When an Asp.Net 2.0 application is loaded, the attributes (and behavior) of the various Asp.Net providers (membership, roleManager, profile and others) are retrieved from sections in machine.config (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.) If the web application includes a web.config file, the configuration sections contained therein may supplement or override the default behavior.

So how do you programmatically determine if a provider is getting its configuration from the default (machine.config) file or from an application-specific (web.config) file?

I recently had to deal with this issue in testing for various potential user problems with the Membership Manager Control. I was simulating a fairly common scenario where users might configure their AspNetSqlMembershipProvider to store passwords in an encrypted format but forget to provide a machineKey section. The machineKey section defines how to encrypt/decrypt various types of information and, if not defined in web.config, will produce autogenerated values. Anyone who has tried to go with an encrypted rather than hashed passwordFormat will have undoubtedly encountered the following message when they attempt to run the web application:

You must specify a non-autogenerated machine key to store passwords in the encrypted format. Either specify a different passwordFormat, or change the machineKey configuration to use a non-autogenerated decryption key.

This exception is thrown by the AspNetSQLMembershipProvider to force the web application developer to provide a machineKey section in web.config. This requirement is well documented and several excellent resources are available on the Internet to help you generate the elements needed to create your own custom machineKey configuration section.

So in my situation, I wanted to prevent users from changing an individual member’s passwordFormat to Encrypted if the machineKey was not specified in web.config. I would need a way to determine this at runtime.

Well, it’s easy enough to get a strongly typed MachineKeySection object. The following VB.Net method illustrates how to get an instance of the machineKeySection class for the current web project:

Public Shared Function GetMachineKeySection() As System.Web.Configuration.MachineKeySection

Static section As MachineKeySection
If section Is Nothing Then

section = CType(System.Web.Configuration.WebConfigurationManager.GetSection("system.web/machineKey"), MachineKeySection)

End If
Return section

End Function

(Note that "system.web/machineKey" is case sensitive)

And when you check the resulting instance, you will get information in fields such as decryption, decryptionKey, validation and validationKey – whether or not a machineKey section exists in web.config.

So how can you programmatically tell if machineKey contains a non-autogenerated decryption key?

The ElementInformation class is typically available as a property of sections such as machineKey and can tell you if a particular element is a collection, if it can be modified and even the line number where it is defined in its configuration file. And, of course, Microsoft gives us the IsPresent property which tells us whether or not the element actually exists in the configuration file. ElementInformation.IsPresent returns a Boolean and is easy to use as shown in the VB.Net method listed below.

Public Shared Function HaveMachineKey() As Boolean

Dim section As MachineKeySection = GetMachineKeySection() ' see above

            If Not section Is Nothing Then
               section.ElementInformation.IsPresent
            End If

End Function

The model for strongly typed configuration classes has been around since .Net 1.0 and is available for WinForms as well as WebForms applications. Custom configuration classes are relatively easy to create and provide a big step up from INI files. In the 2.0 .Net Framework, configuration classes are even easier to create and provide lots of great new capabilities. This ability to inherit and override configuration settings does a great job in supporting the provider model and features such as the ElementInformation class give the programmer all the information he/she needs to determine the source of any particular configuration section.

Brian Mishler

http://www.qualitydata.com

Translated Configuration Exception Message, part 1

Brian Mishler — Tue, 18 Apr 2006 21:56:21 GMT

This is one of those “..note to self” blogs to document for future reference the meaning of the exception message:

Format of the initialization string does not conform to specification starting at index 0

To me this actually means:

When the provider is being initialized with a collection of key/value pairs, the string that defines those key/value pairs is not properly formatted.

Perhaps that would be obvious to most but in my case, the exception would be difficult to track down in the field since a provider to my provider was actually throwing the exception. In particular, my provider (AspNetSqlMembershipProvider) had a properly configured ConnectionStringName attribute but the format of the corresponding connection string (in the web.config connectionstrings section) was not properly formatted as “data source=…”. (I had gone with the proverbial connectionString="Foo" to see if/how it would blow.)

In fact, it was the SqlClient Data Provider that was originating the exception, at least in my case.

I post this here so that if I get “oldTimers” or if anyone else suffers from the exception, it may help offer a clue.

Brian Mishler

http://www.qualitydata.com

Asp.Net Membership Password Administration

Brian Mishler — Tue, 18 Apr 2006 01:47:20 GMT

The Asp.net membership provider was designed to allow for self-service password management but through an understanding of the configuration options as well as a combined use certain provider methods, web site administrators can effectively manage member passwords. This article briefly summarizes the various settings and methods which can be combined to administratively manage passwords in an Asp.Net membership system based on the default SQLMembershipProvider.

The following (web.config) configuration options define how the AspNetSqlMembershipProvider behaves:

enablePasswordRetrieval – Enables/disables the membership provider’s GetPassword method. Note that GetPassword will always throw an exception if the user’s password is hashed. Default value is false. Requires the password answer unless “requiresQuestionAndAnswer” in web.config is set to false.

enablePasswordReset – Enables/disables the membership provider’s ResetPassword method, which can be used to produce a randomly generated password. Default value is true. ResetPassword requires the user’s passwordAnswer unless “requiresQuestionAndAnswer” in web.config is set to false.

requiresQuestionAndAnswer – Alters the behavior of the GetPassword and ResetPassword methods to require or not require the password answer parameter. Default value is true. This method is the key for administrative management of passwords since, by turning it off, administrators can retrieve or reset passwords.

passwordFormat – Defines how passwords will be stored when membership records are created. Note that once a membership record has been created, functions such as ChangePassword and ResetPassword will continue to store the credentials in the original passwordFormat, even if web.config is changed to use a different password format.

Clear the password and password answer are stored in clear text. The passwordSalt field (in the database) is left blank.

Encrypted the password, password answer and passwordSalt are stored in an encrypted format within the database using the key information supplied in the machineKey element of web.config

Hashed the password and password answer are hashed using a one-way hash algorithm and a randomly generated passwordSalt value.

Microsoft set the default value of passwordFormat to Hashed in order to promote their secure web initiative but for many applications, this level of security is overkill and can create inconveniences in managing passwords.

Given the above information, there are a number of approaches that can be taken to administratively manage membership passwords. Note that “administrative” management implies that the administrator does not know the member’s password or password answer.

Retrieving a member’s password

The GetPassword method may be used to retrieve a member’s password and, at first glance, appears to require the password answer. By setting “requiresQuestionAndAnswer” to false in web.config, the GetPassword method can be called with an empty password answer and therefore can be effectively used to administratively retrieve a member’s password. Note that “enablePasswordRetrieval” must be set to true in web.config to enable the GetPassword method:

If password is:

Clear text Simply call the GetPassword method with the username and without the need for a password answer to retrieve the password

Encrypted Simply call the GetPassword method with the username and without the need for a password answer to retrieve the password

Hashed Not possible, however the password may be reset as described below.

In Visual Basic, you can call the shared GetPassword method as illustrated below. Note that the second parameter would be for the password answer if “requiresQuestionAndAnswer” were true in web.config.

Dim password As String = Membership.Provider.GetPassword(userName, String.Empty)

Resetting a member’s password

The ResetPassword method may be used to generate a new, randomly generated password and, at first glance, appears to require the user’s password answer. By setting “requiresQuestionAndAnswer” to false in web.config, the ResetPassword method can be called with an empty password answer to set a user’s password to some new randomly generated value. ResetPassword works with all password formats (clear, encrypted, hashed).

In Visual Basic, you can call the shared ResetPassword method as illustrated below. Note that you can pass Nothing for the second parameter, passwordAnswer.

Dim newPassword As String = Membership.Provider.ResetPassword(username, Nothing)

Changing a member’s password

In some organizations, a Customer Service department may wish to change a user’s password to a new known value, perhaps in response to a customer request. The ChangePassword method, which appears to handle this need, unfortunately requires the original user password which is usually unavailable to the site administrator. By setting “requiresQuestionAndAnswer” to false, “enablePasswordRetrieval” to true and “enablePasswordReset” to true in web.config, the ResetPassword and ChangePassword methods can be used to change a user’s password to a known value, regardless of the password format:

Clear text Call the GetPassword method with the username and without the need for a password answer to retrieve the password. Now, armed with the password, call ChangePassword to set the password to a desired value.

Encrypted Call the GetPassword method with the username and without the need for a password answer to retrieve the password. Now, armed with the password, call ChangePassword to set the password to a desired value

Changing a member’s Password Question and Password Answer

In some situations, the Customer Service department may wish to modify a member’s Password Question and Password Answer. This is easily accomplished if passwords are encrypted or maintained in clear text. For hashed passwords, however, a password-reset is also required since the provider method, ChangePasswordQuestionAndAnswer, requires the member’s password which is not retrievable. By setting “requiresQuestionAndAnswer” to false, “enablePasswordRetrieval” to true and “enablePasswordReset” to true in web.config, the member’s Password Question and Password Answer may be reset:

Clear text Call the GetPassword method with the username and without the need for a password answer to retrieve the password. Now, armed with the password, call ChangePasswordQuestionAndAnswer to set the Password Question and Password Answer to a desired value.

Encrypted Call the GetPassword method with the username and without the need for a password answer to retrieve the password. Now, armed with the password, call ChangePasswordQuestionAndAnswer to set the Password Question and Password Answer to a desired value.

Hashed Call the ResetPassword method with the username and without the need for a password answer to reset the password to a new random value. Using the newly generated password, call ChangePasswordQuestionAndAnswer to set the Password Question and Password Answer to a desired value. Optionally call ChangePassword to set the password to a more user-friendly value.

Changing the password format

As web sites mature, website administrators sometimes regret their original (sometimes unintended) choice in passwordFormat when using the AspNetSqlMembershipProvider. That is, membership passwords may be clear text when a hashed format is desired or vice versa. Microsoft’s decision to implement hashing in the default AspNetSqlMembershipProvider was wise and conservative but for many web sites with minimal security requirements, the password system can become cumbersome. By directly calling a couple of the AspNet stored procedures, it is possible to change the password format:

Note: If the passwordFormat is initially “Clear” or “Encrypted”, use the membership.provider.GetPassword method to cache the original password before calling the stored procedures.

1. Use the stored procedure aspnet Membership GetPasswordWithFormat to retrieve the current passwordSalt.

2. Use the stored procedure aspnet Membership ResetPassword to set the passwordFormat to its intended (integer) value. The stored procedure requires readily available parameter values including passwordSalt (retrieved earlier), password (empty string) and passwordAnswer (Null).

At this point, the membership record has been placed into an initialized (unusable) state and the PasswordAnswer has been lost. If the original password was hashed, then it too will be unrecoverable. The provider methods listed below and described in previous sections allow for resetting the credentials and, as they are used, the password and password answer will be stored in the new password format (clear, encrypted, hashed.)

1. Call the ResetPassword method to generate and retrieve a new random Password. Remember that the second parameter (answer) is not required if “requiresQuestionAndAnswer” is set to false in web.config.

2. Call the ChangePassword method, using the now-current password retrieved in the previous step, to set the password to a desired value. If the original password was saved at the start of the procedure, it may be restored at this point.

For originally un-hashed passwords, the preceding steps allow for a change of passwordFormat with complete restoration of the original password.

The Password Answer could have easily been retrieved from the database at the outset if it was stored in clear text. In the case of an encrypted Password Answer, a more complicated approach which involves the provider’s protected DecryptPassword method could have been used to cache the original Password Answer. If the original Password Answer were available, it could be restored with a call to the ChangePasswordQuestionAndAnswer provider method.

So, what can be done if the Password and/or Password Answer had to be sacrificed in favor of a new passwordFormat? One solution might be to reset everyone’s credentials then send them by Email. Another solution might be to place a notice onto the web site that informs users and provides further instructions. Either way, the web site should leverage the self-service membership controls which allow the member to reset his/her own credentials. The following outlines a series of steps that can be taken:

1. A new arbitrary password can be assigned using either the ResetPassword or ChangePassword provider method. Similarly, a new arbitrary Password Question and Password Answer can be assigned using the ChangePasswordQuestionAndAnswer provider method.

2. Since the user will not know his/her new credentials, ensure the Login Control includes the necessary properties (PasswordRecoveryText and PasswordRecoveryURL) to link the user to a page that includes a PasswordRecovery Control.

3. Recall that the PasswordRecovery Control is driven by the provider settings in web.config. In particular, ensure that “requiresQuestionAndAnswer” is set to false so the PasswordRecovery Control does not prompt the user for a Password Answer. Also, ensure that the SMTP setting is specified in web.config so that the Email will be sent. If the membership record uses a hashed password format then a new (random) password will be sent, otherwise the password you assigned in the previous step will be sent.

Conclusion

Armed with a little knowledge, it is possible to use the membership provider methods to perform basic administrative functions for an otherwise self-service web site. It is possible (although probably undesirable) to have a mix of clear, encrypted and hashed passwords in the same database. Depending on the passwordFormat for a particular record, varying levels of administrative control are available. For the AspNetSqlMembershipProvider, it is possible to change the passwordFormat for a particular record using a combination of built-in stored procedure calls and membership provider methods.

Microsoft has done a good job in engineering the membership provider system and has really left no security holes. The procedures outlined here utilize a combination of built-in stored procedures as well as standard provider methods to accomplish certain activities that are routinely required of site administrators.

Brian Mishler

http://www.qualitydata.com

Why the Provider Model is so important to ISV's

Brian Mishler — Fri, 14 Apr 2006 16:25:26 GMT

As an Independent Software Vendor (ISV), I make my living writing a software program and (hopefully) selling it many times. For the most part, the application meets the customer’s requirements right “out of the box” and if there is a gap, the customer is usually able to work around it. Every now and then, a potential customer will dangle the carrot out there, that if certain features are added then they’ll buy a lot of copies. Or, they would buy it if it could be integrated with their existing XYZ-system.

Now I’m not talking about the practice of accepting customer suggestions for a systematic improvement of a maturing product. I’m talking about adding appendages where they just don’t belong. Over the years, I’ve occasionally succumbed to these pressures and in some cases, the products were better off for it. Other times, the extra features were like anchors around our feet as now had customer-specific business rules in our mainstream product.

The Provider Model

I’m sure the Provider Model has been around for a while but I first heard the term “Provider” back when Microsoft was introducing its “Universal Data Access” strategy (I seem to recall this was all part of the transition to MDAC.) For the next few years, of course, we all used the “ODBC Provider” or the “SQL Server Provider” in our database applications and (at least I) did not think much more of it.

In general, the provider model is a design pattern that allows, through configuration, an alternate provider of application functionality to be substituted with requiring modification to the primary application.

(There’s probably a better text-book definition for this but my definition suits me just fine)

A few years back, I read a couple of articles on MSDN about “Providers” and proceeded to build my own for one of our products, the PocketForms Web Service. I was intrigued about the idea of letting customers easily override the default implementation of any of my web methods and figured this might provide a nice “catch all” for the occasional special-requirements customer. Back then, there was no base provider class in the .Net Framework but several good examples were available for guidance.

I found that most of the work was actually in setting up various configuration classes that would be used to manage optional user settings. The application, itself, required some fairly straight-forward design changes, mainly in creating a new “MustInherit” base class that defined the interfaces that my existing class already implemented. All-in-all, it took just a couple of days to retrofit my existing application with this new design pattern.

Fantastic Return on Investment

I must say that the investment in learning about and implementing the Provider Model has been one of the best decisions I have ever made professionally. As it turns out, most of our customers take advantage of this in one way or another. Some have custom authentication requirements, some want to do special handling with posted data and others just want to log certain activities.

Last year, we released our Sharepoint Bridge which is a “shrink wrapped” provider to make our product work with Sharepoint Portal Server and Windows Sharepoint Services and have attracted a lot of attention from organizations that wanted an easy way to push mobile data into their existing Sharepoint-based intranet. This extra capability can be customized and improved on its own product cycle without ever affecting the functionality of the primary product. And, as we upgrade our web service with additional features, our custom providers continue to work.

Now easier than ever

With the release of the .Net Framework 2.0, Microsoft included a base provider class in the framework itself. We were able to dump all of our plumbing code and simply inherit our base classes from the new System.Configuration.Provider.ProviderBase class. The various configuration (ConfigurationSection, ProviderCollection, etc.) classes have also been simplified, so we cleaned up our existing configuration code as well.

There are plenty of articles on MSDN and elsewhere on using the provider model, so it would be redundant for me to go through all that here. In a future post, I plan provide a real working example in case anyone wants a nice starter project.

Not just for Asp.Net

With the release of Visual Studio 2005, Microsoft showed off the new Asp.Net Membership System in just about every presentation they gave. Everyone was impressed with the instant login and user creation controls and when Microsoft was asked the question “what if we want to change the implementation”, they were able to point to the provider-based implementation of their Membership System. Since there is such a high adoption rate of the Asp.Net Membership System, many folks associate the term “provider” with the Role, Membership and Profile providers in Asp.Net. Many programmers will go on to assume that this means the “AspNetSqlRoleProvider”, “AspNetSqlMembershipProvider” and “AspNetProfileProvider” and lose sight of the fact that these are just the default (if not the most common) implementations of the base provider classes.

More and more ISV’s are recognizing that this model is not only useful for supporting unplanned circumstances but will also become more in demand with the increased adoption rate of Microsoft’s development platforms. The investment is minimal and the potential rewards are significant. As I evaluate new applications, I have gotten into the habit of reading the configuration files and lately have seen an increased number of “shrink wrap” programs that have some form of provider-based implementation. One good example is Telligent’s Community Server that appears to have largely been built on base provider classes. I have not seen much documentation on this but I would assume that Telligent built it this way so that organizations could swap out some of the implementation.

The provider model works well for Asp.Net (web) applications since the appropriate provider is loaded once and based on the settings in Web.Config. It also works well for WinForms applications, although a change in the application’s configuration file does not automatically cause a running application to restart and reload a different provider.

From one ISV to another…

So, if you are an ISV building solutions on the Microsoft .Net platform, you owe it to yourself to consider a provider-based implementation of your application. You’ll find you are able to satisfy many unexpected requirements and not have to saddle your application with extra features that will need to be optionally disabled in future releases. Another big benefit is the additional revenue stream you open up with new add-on products like your “Oracle Provider” or “SAP Provider”.

I love this subject and, while I have had a lot of success in actually using it, keep finding there is more to learn. Your comments are welcome.

Brian Mishler

http://www.qualitydata.com

Bite the bullet and invest in learning .Net

Brian Mishler — Wed, 12 Apr 2006 03:06:38 GMT

I’ve been an Independent Software Vendor (ISV) since 1991 and have created marketable software products using various flavors of “xBase” (dBase, FoxPro, Clipper) and eventually every version of Visual Basic since version 1.0. I’ve loved every one of those development tools (except perhaps VB 4) and built lots of great products, many that are still selling today.

Then I discovered Microsoft .Net

In spite of a decade of experience, I felt like I was starting all over again. The learning curve was steep and I actually had to “unlearn” a lot to understand totally new ways of doing common things. It’s hard to spend hours learning a new way of doing something when can “knock it out” in minutes the old way. I’ve been learning this technology for nearly five years and am still discovering uncharted territories every day.

Has it been worth it? You bet it has!

I can now build products that run on a variety of platforms and can be used online, offline and any time. I can do all of this in much less time and with much less code. This means that there is less to go wrong and it is easier to make changes. All this adds up to improved Quality and increased customer satisfaction.

Moving forward, the next decade promises dramatic returns on my investments. And with all the cool technology that Microsoft is planning, I just know it is going to be a lot of fun.

Those who know me will laugh when I say (again) “this is the best time to be a programmer”. – This time I really mean it!

Brian Mishler

http://www.qualitydata.com

Displaying a pop-up data entry screen with Asp.Net Atlas

Brian Mishler — Tue, 11 Apr 2006 02:15:10 GMT

I have a web application that requires a modal “pop-up” window for collecting extra data from the user. I have done this in the past using JavaScript to open a new window but was wondering if Microsoft’s Atlas library might have something to do this right “out of the box”. I did not find a specific method for doing anything like this but the atlas:DragOverlayExtender and atlas:UpdatePanel looked like them might offer some functionality do get the job done.

Don’t you always worry that there is a one-line solution out there as you proceed to kludge something together? I searched Google and read the Atlas Documentation and lots of blogs but could not find something that did this. With my luck, someone will respond with “Oh, just…”

Anyway, I have come up with an approach that is not really modal (yet) but actually gives me ideas for some very interesting possibilities. Essentially, I place a hidden panel, complete with all of the user interface elements I need for collecting extra input, directly onto the form. Now this is not really exciting except that, with Atlas, I can show and hide the panel without client-side javascript and without a post-back. Further, I can use server-side code to process the data entered into the panel and update other controls on the web form, again without a post-back. So, while the example is fairly trivial, it illustrates how Atlas can greatly simplify something that used to be a great pain with lots of difficult-to-debug javascript.

This is what the page looks like initially, with the input panel and finally with the collected data displayed. Note that a postback is never required.

This is what the solution looks like:

And here is the code for default.aspx. You can simply copy/paste this into a Visual Studio 2005 project that has the Microsoft.Web.Atlas.dll assembly in its Bin folder as well as the requisite entries in web.config. (A ready-to-go project is also available in a Zip file at the bottom of this post.)

<%@ Page Language="VB" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Protected Sub btnPopup Click(ByVal sender As Object, ByVal e As System.EventArgs)

' show Popup panel

CType(Me.popupUpdatePanel.FindControl("pnlPopup"), Panel).Visible = True

End Sub

Protected Sub btnApply Click(ByVal sender As Object, ByVal e As System.EventArgs)

' use FindControl to locate various controls

Dim txtName As TextBox = CType(Me.popupUpdatePanel.FindControl("txtName"), TextBox)

Dim txtPhone As TextBox = CType(Me.popupUpdatePanel.FindControl("txtPhone"), TextBox)

Dim lblResult As Label = CType(Me.popupUpdatePanel.FindControl("lblResult"), Label)

Try

' This is Good Old Server Side code. We could look up database info, etc.

lblResult.Text = txtName.Text & ", " & txtPhone.Text

Catch ex As Exception

If lblResult IsNot Nothing Then lblResult.Text = ex.Message

End Try

' hide the panel

btnCancel Click(Nothing, Nothing)

End Sub

Sub btnCancel Click(ByVal sender As Object, ByVal e As EventArgs)

' hide popup panel

CType(Me.popupUpdatePanel.FindControl("pnlPopup"), Panel).Visible = False

End Sub

</script>

<title>Untitled Page</title>

</head>

<body>

<atlas:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering="true" />

<div>

<atlas:UpdatePanel ID="popupUpdatePanel" runat="server" Mode="Always">

<asp:Panel ID="pnlPopup" runat="server" Height="200px" Width="300px" BackColor="gainsboro"

Visible="false" BorderColor="gray" BorderStyle="Outset" BorderWidth="2">

Enter User Info</div>

Name: <asp:TextBox runat="server" ID="txtName" /><br />

phone: <asp:TextBox runat="server" ID="txtPhone" /><br />

<asp:Button ID="btnApply" runat="Server" Text="Apply" OnClick="btnApply Click" />

<asp:Button ID="btnCancel" runat="Server" OnClick="btnCancel Click" Text="Cancel" />

</asp:Panel>

<asp:Button ID="btnPopup" runat="server" Text="Prompt for User Info" OnClick="btnPopup Click" />

<asp:Label ID="lblResult" runat="server" />

</ContentTemplate>

<atlas:ControlEventTrigger ControlID="btnPopup" EventName="Click" />

</Triggers>

</atlas:UpdatePanel>

</div>

</form>

</references>

</components>

</page>

</script>

</body>

</html>

This is my foray into Atlas and, as someone who has done a good bit of client-side javascript, I am quick to jump on the Atlas band-wagon. I actually hope there is or will be an <Atlas:ModalPanel..> control but if not, I can already see where the basic controls provided in the March CTP can be used to do some interesting stuff. So if anyone knows of the “one liner”… please let me know.

Brian Mishler

http://www.qualitydata.com

Download: AtlasWebSite1.zip

Dynamic MasterPages, Part 2

Brian Mishler — Mon, 10 Apr 2006 04:18:29 GMT

In an earlier blog, I mentioned how through the use of Dynamic MasterPages, I could have my web site change its format based on some arbitrary condition such as the browser type. Here, I have assembled an example to illustrate Dynamic MasterPages in action.

For this sample, I have created a single web form that contains our page content. This form (childPage.aspx) gets its layout from a master page (masterpage1.master) but when a particular condition is encountered (query parameter “foo” provided), the child will use the layout from a different master page (masterpage2.master).

Since we might have dozens of pages that need to dynamically change their layout, I have created a class called “WebFormBase” that inherits from System.Web.UI.Form and as I add each new web form, I will have it inherit from my custom base class rather than from the default System.Web.UI.Form. Now when I add code into “WebFormBase”, my child form (and any other forms that derive from “WebFormBase”) will enjoy that code.

This is a good practice, especially in large web sites, for many obvious reasons.

To load our “childPage” with different query parameters, I created “default.aspx” with two hyperlinks.

The first hyperlink loads “childPage.aspx” with no query parameters.
The second hyperlink loads “childPage.aspx” with the query parameter, “foo”.

This figure illustrates how the same child page looks when different (dynamic) master pages are applied:

Here is my custom base class, WebFormBase, into which I have added a single event handler to check for the “foo” querystring parameter.

public class WebFormBase : System.Web.UI.Page

{

protected override void OnPreInit(EventArgs e)

{

base.OnPreInit(e);

if (Request.QueryString.Get("foo") == null){

this.MasterPageFile="~/MasterPage1.master";

}

else{

this.MasterPageFile="~/MasterPage2.master";

}

The following code is for “ChildPage.aspx”, the web page whose layout is controlled by the two master pages. Notice that the MasterPageFile attribute is initially defined as “MasterPage1.master” and also that Inherits=”WebFormBase” causes the web form to inherit from our custom class rather than the built in webforms base class.

<%@ Page Language="C#" MasterPageFile="~/MasterPage1.master" Title="Variable Page" Inherits="WebFormBase" %>

<asp:Content ID="foo" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">

<div style="background-color:White;padding:10px 10px 10px 10px">
This is the content that is embedded in the child page. Depending on the dynamically selected master page, my surroundings may differ.
</div>

</asp:Content>

One final note is that since I have defined that ContentPlaceHolderID=”ContentPlaceHolder1”, the alternate master page must have a content place holder named “ContentPlaceHolder1” or the page will erupt at runtime.

Feel free to download and run the sample web site which is available as a Zip file near the bottom of this post. As always, any comments and opinions are appreciated.

Brian Mishler

http://www.qualitydata.com

Download: DynamicMasterPageSample.zip

DynamicMasterPageSample.zip (2.51 KB)

Using existing Asp.Net Membership data with CommunityServer

Brian Mishler — Mon, 10 Apr 2006 02:12:06 GMT

I really like the new Version 2.0 of CommunityServer and have been trying to figure out how to best integrate it with my existing web site. Since I already have several thousand members registered on my site, I would like to either migrate their data into Community Server or find a clean way to share authentication information so my existing members do not have to maintain separate passwords for the existing customer-service and new community server functions.

I figured I would ask Telligent about the Asp.Net Forms Authentication Module for CommunityServer so I initiated contact with their Sales team. While I waited for a response, I decided to open up the database and figure out what is going on inside.

The first thing I noticed was that the CommunityServer database includes the tables and stored procedures used by the AspNet membership system. These include AspNet Applications, AspNet Membership, AspNet Profile, AspNet Users and several more.

A quick look at web.config confirmed that CommunityServer has created custom providers that (presumably) inherit from SQLMembershipProvider, SQLRoleProvider and SQLProfileProvider.

I really like the fact that CommunityServer leverages the AspNet membership providers for generic mainstream authentication functions. I believe this is a trend we will see more of now that Microsoft has established a de-facto standard. Telligent has done the smart thing by extending the base providers with their own customized versions that provide application-specific functionality and utilize additional data tables.

With hopes of sharing common membership information, I set out to understand the extra information required by CommunityServer for records that were initiated from my own system. After a bit of trial and error I found that CommunityServer expects each user to be a member of the "everyone" role in the AspNet membership system and that a record is required for each member in the cs users and cs profiles tables which maintain Community-server specific informaiton on each member. At this point, I was feeling pretty confident about my chances of sharing CommunityServer's membership system with my own, so I imported my own data into the CommunityServer database. After doing so, I was able to log into CommunityServer with one of my imported user accounts and I figured I was done.

Knowing a thing or two about Asp.Net providers, I reset the "ApplicationName" attribute for each of the three providers (SqlProfileProvider, SqlRoleProvider and SqlMembershipProvider) in my own application's web.config. This would need to be "dev" in order that any new records created by my system would wind up with the same ApplicationID that is used by CommunityServer's providers. Finally, I changed my connection string to point over to CommunityServer and then "let 'er rip".

Curses! It didn't work. My application was dead and I was being told that Procedure or function aspnet Membership GetPasswordWithFormat has too many arguments specified.

Hmmm. I remember this. It was the same error message I got when I upgraded from the .Net 2.0 Beta to the live version last October. Sure enough, as I looked into it a little more, I found that CommunityServer 2.0 is shipping with the beta versions of the Asp.Net membership providers. A lot of early adopters will remember this situation: Microsoft told us that they reserved the right to change the product prior to final release--and they did. The membership tables did not change but many of the stored procedures did. For the folks that built sites with the basic providers, the issue was easily resolved with the AspNet regSql utility that comes with the framework. (It can be found at c:\windows\microsoft.net\framework\v2.0.50727\aspnet regsql.exe.)

Here are (most of) the differences:

Stored Procedure	Beta Version Parameters	Version 2.0 Parameters
aspnet Membership GetPasswordWithFormat	@ApplicationName NVARCHAR(256)	@ApplicationName nvarchar(256)
Provider Exception: Procedure or function aspnet Membership GetPasswordWithFormat has too many arguments specified	@UserName NVARCHAR(256)	@UserName nvarchar(256)
		@UpdateLastLoginActivityDate bit
		@CurrentTimeUtc datetime

aspnet Membership UpdateUserInfo	@ApplicationName NVARCHAR(256)	@ApplicationName nvarchar(256)
Provider Exception: Procedure or function aspnet Membership UpdateUserInfo has too many arguments specified	@UserName NVARCHAR(256)	@UserName nvarchar(256)
	@IsPasswordCorrect BIT	@IsPasswordCorrect bit
	@UpdateLastLoginActivityDate BIT	@UpdateLastLoginActivityDate bit
	@MaxInvalidPasswordAttempts INT	@MaxInvalidPasswordAttempts int
	@PasswordAttemptWindow INT	@PasswordAttemptWindow int
	@TimeZoneAdjustment INT	@CurrentTimeUtc datetime
		@LastLoginDate datetime
		@LastActivityDate datetime

aspnet Profile GetProperties	@ApplicationName NVARCHAR(256)	@ApplicationName nvarchar(256
Provider Exception: Procedure or Function 'aspnet Profile GetProperties' expects parameter '@TimeZoneAdjustment', which was not supplied	@UserName NVARCHAR(256)	@UserName nvarchar(256)
	@TimeZoneAdjustment INT	@CurrentTimeUtc datetime


aspnet Membership GetUserByName	@ApplicationName NVARCHAR(256)	@ApplicationName nvarchar(256)
Provider Exception: Procedure or Function 'aspnet Membership GetUserByName' expects parameter '@TimeZoneAdjustment', which was not supplied	@UserName NVARCHAR(256)	@UserName nvarchar(256)
	@TimeZoneAdjustment INT	@CurrentTimeUtc datetime,
	@UpdateLastActivity BIT = 0	@UpdateLastActivity bit = 0

aspnet Membership GetUserByUserId	@UserId UNIQUEIDENTIFIER	@UserId uniqueidentifier
Provider Exception: Procedure or Function 'aspnet Membership GetUserByUserId' expects parameter '@TimeZoneAdjustment', which was not supplied	@TimeZoneAdjustment INT	@CurrentTimeUtc datetime
	@UpdateLastActivity BIT = 0	@UpdateLastActivity bit = 0


aspnet Membership CreateUser	@ApplicationName NVARCHAR(256)	@ApplicationName nvarchar(256)
Provider Exception: Procedure or Function 'aspnet Membership CreateUser' expects parameter '@TimeZoneAdjustment', which was not supplied	@UserName NVARCHAR(256)	@UserName nvarchar(256)
	@Password NVARCHAR(128)	@Password nvarchar(128)
	@PasswordSalt NVARCHAR(128)	@PasswordSalt nvarchar(128)
	@Email NVARCHAR(256)	@Email nvarchar(256)
	@PasswordQuestion NVARCHAR(256)	@PasswordQuestion nvarchar(256)
	@PasswordAnswer NVARCHAR(128)	@PasswordAnswer nvarchar(128)
	@IsApproved BIT	@IsApproved bit
	@TimeZoneAdjustment INT	@CurrentTimeUtc datetime
	@CreateDate DATETIME = NULL	@CreateDate datetime = NULL
	@UniqueEmail INT = 0	@UniqueEmail int = 0
	@PasswordFormat INT = 0	@PasswordFormat int = 0
	@UserId UNIQUEIDENTIFIER OUTPUT	@UserId uniqueidentifier OUTPUT

If you built a custom providers for the beta-version of Asp.Net, a code change would be required to work with the released version of the schema.

At first glance, it appeared that Telligent overlooked the change, but as I performed additional research, I found that their released version was designed to provide default backward compatibility with their original (.Net 1.1) product but also an upgrade path for the folks that want compatibility with the Asp.Net 2.0 Membership System. The CommunityServer 2.0 SDK (http://communityserver.org/files/40/releases/entry516270.aspx) includes a readme.txt file that explains what they did and why they did it. In that document, they explain that "Telligent will be providing both Framework 1.1 and 2.0 compatible binaries." You can update the binaries (dll) files and also run a script which will update the Schema, but at the expense of 1.1 compatibility. The readme.txt goes on to explain how to replace the web.config and communityserver.config files and also how to locate the SQL Script file that may be used to upgrade the default schema to that of Asp.Net 2.0.

I am not sure why Beta versions of the Asp.Net schema are involved at all, however, to utilize the final Asp.Net 2.0 database Schema, you need to do the following:

1. Substitute CommunityServer.ASPNet20MemberRole.dll for CommunityServer.MemberRole.dll in the \bin folder

2. Modify CommunityServer.config to have the MemberRoleProfileProvider use classes from the new dll. (swap out the config file)

3. Swap out the provided web.config file for the one in the SDK. (not sure of the differences)

4. Update the database schema using their provided script.

-- The only thing left is to get the ASPNet20MemberRole.dll

Once I do these things, I am hopeful that I will have a database schema that works with the "vanilla" Asp.Net providers. If I can get all this to work, then I should be able to share my membership with that of CommunityServer.

With all respect due to the great folks at Telligent, I would like to suggest that they update the default installation (for new users) to incorporate the released version of the Asp.Net membership schema which should now be considered the gold standard. I believe there are plenty of folks that might wish to unify their membership database with that of CommunityServer and it can be a very easy process if the database schema is consistent. If anyone knows more or has insight on this subject, I invite your suggestions and comments.

Brian Mishler

http://www.qualitydata.com

Dynamic Master Pages

Brian Mishler — Mon, 10 Apr 2006 01:21:53 GMT

So in another blog, I mentioned a technique where I could hide obsolete content throughout my site by simply placing ContentPlaceHolders into hidden panels in the MasterPage. In that context, this practice might be a temporary fix pending a visit to each page in the web site.

Since our business involves a lot of mobility and we invite customers to visit our web site from their pocket pc, I’ve been thinking that this technique of "hiding" content placeholders might offer a better way to create a Pocket PC friendly user experience.

Currently, I substitute the CSS file or even redirect the user to a special section of my web site whenever I detect they are using Pocket IE. You can see this in action if you visit http://www.pocketforms.net (first in your browser then from your pocket pc.)

With Dynamic MasterPages, I can programmatically select a specific master page based on the requestor's browser type. The pocket pc (or smartphone) master page, for example, can reference a style sheet (.CSS file) which is appropriate for the device and also hide superfluous ContentPlaceHolders such as banners and advertising. This approach works much better than a pure CSS approach since hidden content is omitted server-side and never sent to the client.

The following code was inspired by Keith Smith's presentation at the Orlando .Net User Group and can be used to programmatically switch to the Pocket PC friendly master page when a "Windows CE" (pocket pc) browser is detected. In the following code, the master page, pocketpc.master, changes the layout, hides some of the content and references a CSS file with fonts and layout which are better suited for the smaller form factor of a pocket pc.

protected void Page PreInit(object sender, EventArgs e) {
    if(Request.Browser.Browser.ToLower.Contains("windows ce")){
        this.MasterPageFile = "~/pocketpc.master";
        }
        else {
        this.MasterPageFile = "~/MasterPage.master";
    }
}

In VB.Net, it looks like this:

Protected Sub Page PreInit(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.PreInit
    If Request.Browser.Browser.ToLower.Contains("windows ce") Then
        Me.MasterPageFile = "~\pocketpc.master"
    Else
        Me.MasterPageFile = "~\MasterPage.master"
    End If
End Sub

Notice that the opportunity to swap out the MasterPageFile occurs in the PreInit method which occurs early in the page lifecycle (before any custom controls are loaded.) This means that the code cannot be placed into a web custom control (which would be really convenient) but, instead must be placed into the inline code or code-behind file of each page.
Rather than adding this code to each page, this begs for a technique you always hear Carl Franklin, Richard Campbell and their guests talking about on .Net Rocks. That is, to have all your web forms inherit from a custom class rather than from the default, System.Web.UI.Page. When you add behaviors such as variable MasterPages to your custom page class, then all of your (derived) web forms will inherit that behavior as well. Since each of my pages inherit from a class called “webFormBase”, I simply added the code into the Page PreInit event within webFormBase and I get automatic master page switching.

Watch for another blog on this subject for a generic sample of this in action.

Brian Mishler

http://www.qualitydata.com

Default ContentPlaceHolder content in Asp.Net MasterPages

Brian Mishler — Sun, 09 Apr 2006 00:00:40 GMT

Last year, I re-designed our corporate web site to use the MasterPages feature in what was then the Beta version of Visual Studio 2005. I did not bother to read the documentation (which is a testament to their ease-of-use) and if I had, I might have discovered how default template placeholders work.

Like a lot of folks, I created a Master Page first and then created web forms that "used a selected master page". When you create a new form in this way, content panels which correspond to each of the Master Page's ContentPlaceholders are automatically inserted into the page. The next step is obviously to add a bunch of page-specific content into each panel. This was very intuitive and for me, my efforts were well rewarded when I later changed the layout of my master page and everything fell into place.

At last week's Orlando .Net User Group (ONETUG) meeting here in Orlando, Microsoft's Keith Smith gave a really great presentation on Master Pages and Atlas. He demonstrated how to add content into the ContentPlaceHolders of the Master Page, then, by simply omitting the corresponding content panel on a detail page, the (default) content of the Master Page's ContentPlaceHolder is rendered in its place.

Since I had gotten into the habit of adding an empty ContentPlaceHolder to the Master Page then updating each web form with the corresponding content, I might never have realized that the ContentPanel on each form is optional. A few months ago, in fact, I systematically updated every one of my web pages with a ContentPanel corresponding to a new ContentPlaceHolder. Ironically, most of the new content panels received the same user control which, of course, could have been the default content of my new ContentPanel.

Live and learn!

Going the other way, I had a situation where I needed to get rid of obsolete Content Panels on my web pages. Each of my pages included a content panel into which I had placed an image control with a unique graphic for the page. When I deleted the corresponding ContentPlaceHolder from the master page, each of my pages complained that the ContentPanel had an invalid ContentPlaceHolder attribute. While I would ultimately want to visit each page and delete that ContentPanel (or recycle it with different content), I was able to instantly omit the content by restoring the ContentPlaceHolder in my master page and placing it into a hidden Panel Control.

Brian Mishler

http://www.qualitydata.com

How to import existing Asp.Net Membership data into CommunityServer

Brian Mishler — Fri, 07 Apr 2006 02:10:19 GMT

How to import existing Asp.Net Membership data into CommunityServer

I am in the process of enhancing my existing web site with the forums capabilities offered by CommunityServer. Since I already have several thousand members registered on my site, I would like to either migrate their data into Community Server or find a clean way to share authentication information so my existing members do not have to maintain separate passwords for the existing customer-service and new community server functions.

When I saw that CommunityServer was using the Asp.Net membership provider model for authentication, I became hopeful that I might be able to share a common membership database with my own web application since I am using Microsoft's SqlMembershipProvider. Unfortunately, I found that CommunityServer is using a non-standard membership database schema (by default) which is incompatible with Microsoft's SQL providers, so I would not be able to simply point my provider to their membership tables. I did look into Telligent's Asp.Net Forms Authentication module but, as was explained to me, that module provides access for existing CommunityServer users and, of course, my users were not in the CommunityServer membrship database. In any case, I was curious to see if I could import my existing membership users into Community Server.

Part 1 - Import existing membership users into the CommunityServer database

Using SQL Server Import and Export Wizard in SQL Server Management Studio (SQL Server 2005), I was easily able to append the User and Membership data from my existing application into the corresponding tables in the CommunityServer database.

Since AspNet Membership depends on AspNet Users and they both depend on AspNet Applications, I found that the Foreign Key constraints would not let me just check everything off and run the wizard. By running it first for AspNet Applications and then for AspNet Users, I was able to then import AspNet Membership as shown below:

Step 1: Run the wizard for AspNet Applications.

Step 2: Run the wizard again for AspNet Users.

Step 3: Run the wizard one more time for AspNet Membership.

Although my data was now physically located in the same database, a bit of massaging was still necessary to make it usable by CommunityServer. CommunityServer has its own user-related tables and also my user information is stamped with a distinct ApplicationId.

Part 2 - Consolidate the ApplicationID

My data was originally created using mostly generic provider settings and may therefore be distinguished by a unique ApplicationId in the AspNet Applications, AspNet Users, AspNet Membership and AspNet Roles tables. The data which was pre-populated by the CommunityServer Setup Wizard is uniquely identified by its own ApplicationID. Further, the custom providers defined in CommunityServer’s web.config file are configured to use the ApplicationID associated with the applicationName “dev”. As shown here, I actually had two applications in my database at this point.

In order for CommunityServer's provider to "see" the membership data I just imported, I would have to change the ApplicationId in each AspNet Membership and AspNet Users record to the one corresponding to the "dev" applicationName.

So, here is the procedure for modifying the imported data to use the applicationID corresponding to the applicationName “dev”

1. Issue the following statements in SQL Server:

DECLARE @DevApplicationID uniqueidentifier

DECLARE @SlashApplicationID uniqueidentifier

SELECT @DevApplicationID=applicationID FROM AspNet Applications WHERE ApplicationName='dev'

SELECT @SlashApplicationID=applicationID FROM AspNet Applications WHERE ApplicationName='/'

UPDATE AspNet Membership SET ApplicationID=@DevApplicationID WHERE ApplicationID=@SlashApplicationID

UPDATE AspNet Users SET ApplicationID=@DevApplicationID WHERE ApplicationID=@SlashApplicationID

2. Delete the record in AspNet Applications for ApplicationName=”/”. This record is now unused.

DELETE FROM AspNet Applications WHERE ApplicationName='/'

At this point, all of my existing member records are physically contained in CommunityServer's Asp.Net membership tables and have been updated with the same ApplicationID that is referred-to by their custom membership providers. Still, CommunityServer cannot use my imported data since its custom user tables have not been loaded.

Part 3 - CommunityServer’s Roles

I noticed that when a new “guest” user is added into the system, he/she is added to the “Everyone” role. I was not sure if this is a requirement, but it was simple enough to do this for each of my existing (legacy) users with the following SQL Statement:

DECLARE @DevApplicationID uniqueidentifier

SELECT @DevApplicationID=applicationID FROM AspNet Applications WHERE ApplicationName='dev'

DECLARE @EveryoneRoleID uniqueidentifier

SELECT @EveryoneRoleID=RoleID FROM AspNet Roles WHERE loweredRoleName='everyone' AND ApplicationID=@DevApplicationID

INSERT INTO AspNet UsersInRoles (UserID,RoleID) SELECT UserID,@EveryoneRoleID FROM AspNet Users WHERE UserID NOT IN (SELECT UserID from AspNet UsersInRoles)

Note that @EveryoneRoleID is the value in the roleID (GUID) column that corresponds to the “everyone” role in the AspNet roles table.

Part 4 - Importing data into CommunityServer’s User tables

While I was not able to find any documentation on the Internet, I was able, through trial and error, to figure out which minimal data is required in the CommunityServer tables.

The cs users table maps the AspNet membership system’s UserID to the userID which is used internally by CommunityServer. Whereas Asp.Net uses a GUID to uniquely identify users, CommunityServer’s userID is an Integer which is autonumbered. Since most of the fields defaulted to good values, I was able to populate the CommunityServer Users table with the following SQL Statement:

INSERT INTO cs users (membershipID) SELECT UserID from AspNet Membership where UserID not in (SELECT MembershipID as UserID from cs users)

Notice that CommunityServer knows the AspNet membership system’s UserID as “MembershipID” in order that it can use the name “UserID” for its own purposes.

The cs UserProfile table includes colums for tracking the much of the same profile data that is maintained in the AspNet Profile table. I am not sure why it is being kept in both places but I am guessing that the cs UserProfile table is left over from previous implementations and still used as the primary storage location for profile data. In any case, a record is required for each user and the minimum (non-default) data appears to be the UserID, MembershipID and a settingsID.

The UserID and MembershipID were pretty handy for each user and I discovered that the settingsID corresponded to the key field value in the cs SiteSettings table. In my case, there was a single record whose value was 1000. Thus, I was able to initialize the cs UserProfile table with the following SQL Statement:

INSERT INTO cs userprofile (membershipID,UserId,settingsID) SELECT MembershipID,userid,1000 FROM cs users WHERE userid NOT IN (SELECT userid FROM cs userprofile)

Now able to log in

Having tweaked the ApplicationID, imported my existing users, created “everyone” role records for each and inserted records into the cs users and cs userprofile tables, I was now able to log into CommunityServer using an account from my existing web site.

Moving forward, I recognize that the CommunityServer membership system will immediately become unsynchronized with my own. While I am considering using the Asp.Net Forms Authentication module (possibly with some extra work on my part) I am opposed to duplication of any type of information, especially user credentials.

In the meantime, I believe there are plenty of folks that might wish to migrate existing membership data over to CommunityServer and thereafter let CommunityServer handle user credential management. Hopefully, this article will help. If anyone knows more or has insight on this subject, I invite your suggestions and comments.

Brian Mishler

http://www.qualitydata.com

Asp.Net Provider Model: ApplicationNames and the ApplicationID

Brian Mishler — Thu, 06 Apr 2006 02:04:54 GMT

One of the great things about the Asp.Net Membership System is that it was designed to snap into many types of enterprise and off-the-shelf applications to provide a consistent model for common tasks such as authenticating users. Several of the database tables (AspNet Users, AspNet Membership and AspNet Roles) include an “ApplicationID” column, which allows for more than one application to utilize a single database. Therefore, it is possible for two different users of two separate applications to have the same username without experiencing a conflict since the combined ApplicationID & UserName would be distinct.

A master table, AspNet Applications, includes a list of the distinct ApplicationID’s which may be in use by the various membership tables. Since this field is a “uniqueidentifier” (GUID), a separate string field called “ApplicationName” is available for looking up the ApplicationID. The following figure illustrates a record in the AspNet Applications table that maps an ApplicationName “/” to the globally unique ApplicationID.

The ApplicationName can be nearly any string (up to 256 characters) and is originally defined, not in the database, but as an attribute of each of the SQL Server providers (AspNetSqlMembershipProvider , AspNetSqlProfileProvider , AspNetSqlRoleProvider.)

The default attributes for each of the AspNet SQL Providers are defined in machine.config, which is generally stored in c:\windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config. This is an important file that should never be modified so Asp.Net lets you override any of its settings by simply placing sections of the file into a web.config file within your web site.

The following is an excerpt from the <system.web> section of machine.config, which defines the System.Web.Security.SqlMembership provider as the default provider for handling membership. Notice that one of its attributes, applicationName, is set to a backslash.

<system.web>
…
<membership>
<providers>
<clear />
<add connectionStringName="LocalSqlServer"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="true"
applicationName="/"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="7"
minRequiredNonalphanumericCharacters="1"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>
…
</system.web>

If you wanted to store data for more than one application within a single database or if you desired some control over the applicationName which is used in the AspNet Applications table, you can create a web.config file, in the root folder of your web site, to override the applicationName that is specified in machine.config (shown above.)

The following is an excerpt from web.config. Notice that <clear /> is used to remove any default providers (such as the one in machine.config) from memory and that the applicationName has now been set to something more interesting.

Assuming you have already been running the web application, there is likely a pre-existing record in the AspNet Applications table as well as records in the other membership (AspNet Membership, AspNet Users, AspNet Roles) tables that correspond to the ApplicationID for “/”. So guess what happens in the database the first time the application is run after changing the ApplicationName in web.config?

As shown here, a new record, along with a new ApplicationID, has been generated by the provider. All of your existing data including membership, users and roles is still stamped with the original ApplicationID and therefore inaccessible by your provider. This is not a flaw in the system or an oversight on the part of Microsoft. It is simply something you must understand if you intend to modify the applicationName attribute on your provider configuration settings.

Let’s say you have some existing membership records and wish to associate them with the new ApplicationName/ApplicationID. This is very simple to accomplish by issuing the following statements in SQL Server:

UPDATE AspNet Membership SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’

UPDATE AspNet Users SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’

UPDATE AspNet Roles SET ApplicationID=’new-application-id’ WHERE ApplicationID=’old-application-id’

(Please substitute the appropriate GUID for “new-application-id” and “old-application-id”)

The SQLMembership provider’s foreign-key constraints will prevent you from deleting the original AspNet Applications record for “/” until you have successfully modified the ApplicationID values in each of the membership tables. Assuming that you performed the suggested updates then successfully deleted the record in AspNet Applications for “/”, can you see how a new record, again with a backslash “/” in the ApplicationName field, might be re-created the next time you run the web application?

Other providers, such as the AspNetSqlRoleProvider and the AspNetSqlProfileProvider also define default behaviors in machine.config and therein, the attribute for applicationName is “/” by default. If you use roles or profiles in your web application, be sure to override the default implementation for all three AspNet providers in web.config as appropriate for your solution.

Brian Mishler

http://www.qualitydata.com