How do I grab maxInvalidPasswordAttempts from web.config?

Question

Hi

I needed to rewrite lots of asp.net membership stuff since it did not meet my needs. So in my custom verify method I check their passwords if it fails. I grab the aspnet_membership maxInvalidPasswordAttempts column and add 1 to it.

So in my web.config I set it to 10. So I want to grab the value from the web.config and compare to what the user has. How can I do this?

Also I guess when I do this compare in the if statement I would lock the user out?

Answer 1

You should get the config values from web.config in your provider's Initialize method as shown below:

public override void Initialize(string name, NameValueCollection config)
    {
      if (config == null)
        throw new ArgumentNullException("config");

      // Initialize the abstract base class.
      base.Initialize(name, config);

      pApplicationName            = GetConfigValue(config["applicationName"], 
                                      System.Web.Hosting.HostingEnvironment.ApplicationVirtualPath);
      pMaxInvalidPasswordAttempts = Convert.ToInt32(GetConfigValue(config["maxInvalidPasswordAttempts"], "5"));
      // ...

In your application, you would reference it as Membership.MaxInvalidPasswordAttmpts.

There is a full implementation of a custom MembershipProvider on MSDN. I was able to implement a provider within a couple hours using this as an example.

Answer 2

From your application, you can access all of the providers associated with your application through the Providers collection on the Membership class. Then just use the property of the value you are interested in.

Membership.Providers["ProviderName"].MaxInvalidPasswordAttempts

Or you can get the default provider using the following.

Membership.Provider.MaxInvalidPasswordAttempts

Membership is in the System.Web.Security namespace, just in case.

Another approach though is probably to write your own MembershipProvider. Depending on how much customization you are going to be doing, your controllers will be cleaner if you handle all of your custom auth logic in your own provider.