Using the string resources of ASP.NET membership provider in a custom control

Question

I have the request to build a custom control for ASP.NET membership. The control is a kind of CreateUserWizard, but somewhat special. The users are created by our account executives. At their first log in the users enter their user name and initial password, change the password and enter additional information (email) in one transaction!

Building this by customizing CreateUserWizard or another built-in control seems to be the wrong way. I want to build a custom control by using string resources of the built-in controls. Is there a way to access just the resources of ASP.NET membership? Is their a public accessible resource manager or something similar?

Answer 1

The MembershipProvider model exposes all the properties (updated link) that are configurable through the web.config, so once you've got hold of an instance of the correct provider, you should be able to read those properties - what are you unable to read?

Also, most of the default controls allow you to add or replace controls using either the Template elements or through adding additional steps to the create user wizard (for example to populate profile information) - are you able to provide any additional information about what you are trying to do?

Responding to comment/question update

I've had some further thoughts about this, some around the thinking you'll need to have covered, and some about the potential implementation.

Once a user is created by the account executive, and they are informed of their username and temporary password some how (phone/email/whatever), where do they go to log in? Is your main site login control, or are you happy to direct them to a custom login page?

Thinking this through, and depending on the number of login controls you have on the site (i.e. do you just have one place where users can log in, or do you multiple pages), you may want to implement some or all of the following:

1. A custom membership provider that inherits from SqlMembershipProvider (not MembershipProvider, which is abstract, so requires more work), and only really overrides ValidateUser and ChangePassword, passing all other methods back down to the base default.
2. A custom control to capture existing details, email address and new password details.
3. An event handler to capture the Authenticate event of the main login control.

The reason you might want to use a custom membership provider is that it will enable you to take advantage of things like the base provider's concept of an Approved user - the problem with the out of the box SqlMebershipProvider is that it will return false when attempting to validate the user if it's not approved, which makes it hard to distinguish between incorrect passwords and "not approved" users in your custom control.

If you create a custom control and have the custom membership provider discussed above, you can then direct the new users to a page hosting that control which will ensure that they provide all the additional details, when they submit the page you would do the following:

• Call ValidateUser (on your custom membership provider) with the details created by the account executive.
• If that returns true, then call ChangePassword with the user, old and new passwords.
• Call GetUser on your provider to get a MembershipUser, update their email address and "IsApproved" status to true, and pass the MembershipUser object into the UpdateUser method.
• Call FormsAuthentication.SetAuthCookie to set the cookie for the user to tell subsequent requests that the user is authenticated.
• Redirect the user off to a sensible page.

If either of the first two return false, you can then respond back with a sensible message - if ValidateUser fails, then the previously supplied details are wrong, if ChangePassword failed then the new password didn't meet the requirements defined in the provider configuration for length, strength, etc.

You may also want to hook into the Authenticate event of the main login form because you will need to manually check that the user is Approved and if not cancel the login event. A way around this (especially if you're extending the SqlMembershipProvider) is to configure both the out of the box SqlMembershipProvider and your custom provider, set the SqlMembershipProvider as the default, and then in your custom control, instead of calling:

// Gets the "Default" provider configured in the web.config
MembershipProvider provider = Membership.Provider;

You would call:

// Pass the name of your provider into the Providers collection
// Rather than hardcoding this, pass it in as a required parameter
MembershipProvider provider = Membership.Providers["MyMembershipProvider"];

You can use the same method to get a the various properties of the provider that have been configured, such as strength, length, etc.

Bear in mind that the CreateUser method has an output parameter of type MembershipCreateStatus, which has values such as Success, InvalidUserName, InvalidPassword, DuplicateUserName, which should help in returning sensible messages back to the account executives.