When using membership or other providers ASP. net2.0, you must set the application

Symptom 2: If the program runs in vs2005, user a logs on successfully. If user a is viewed under IIS, user a fails to log on.

The reason is that the applicationname setting is missing from the self-defined authentication provider in Web. config.

Original article:Http://lovewangshu.cnblogs.com/archive/2006/04/24/383513.html

You must set the applicationname attribute When configuring ASP. net2.0 using membership or other providers.
Original article:Always set the "applicationname" property when processing ing ASP. NET 2.0 membership and other providers
By Scott Guthrie
Translation: Fan weixiao
Note: retain the English description or translation reference for individual terms.

Scenario:
Membership, roles, or profile features are used to develop an ASP. net2.0 application locally. You have created some new users and everything is fine.

Then copy the program to the remote server (or just move it to another directory on your local server) and run it. For some reason, although we can connect to the membership database, an error will occur during login. It does not throw a connection error, but prompts you with a similar error: "failed to log on, please try again" (LOGIN Attempt unsuccessful, please try again)

Cause:
This common error occurs because the membership (or roles or profile) provider has been added to the web. config of the program. However, the applicationname attribute is not specified (assuming that the bold Section of the following code exists)

<Membership>

<Providers>

<Clear/>

<Add name = "aspnetsqlmembershipprovider"

Type = "system. Web. Security. sqlmembershipprovider, system. Web, version = 2.0.0.0, culture = neutral, publickeytoken = b03f5f7f11d50a3a"

Connectionstringname = "localsqlserver"

Enablepasswordretrieval = "false"

Enablepasswordreset = "true"

Requiresquestionandanswer = "true"

Requiresuniqueemail = "false"

Passwordformat = "hashed"

Maxinvalidpasswordattempts = "5"

Minrequiredpasswordlength = "7"

Minrequirednonalphanumericcharacters = "1"

Passwordattemptwindow = "10"

Passwordstrengthregularexpression = ""

Applicationname = "/" 

/>

</Providers>

</Membership>

If the applicationname attribute is not configured, when adding data to the program database, Asp.net will use the virtual directory path (vroot path) of the Program on the Web server) automatically calculates the value of applicationname. We open the aspnetdb database and read the aspnet_applications table to understand this line:

This table stores an applicationid with a unique value (unique) for each applicationname. Because the applicationname attribute is not specified when registering a user in our program, it is automatically set (calculated) to/website8 (the name of the project that was created earlier ).

If the applicationname attribute is not configured, when adding data to the program database, Asp.net will use the virtual directory path (vroot path) of the Program on the Web server) automatically calculates the value of applicationname. We open the aspnetdb database and read the aspnet_applications table to understand this line:

This table stores an applicationid with a unique value (unique) for each applicationname. Because the applicationname attribute is not specified when a user is registered in our program, it is automatically set (calculated) to/website8 (the name when a project was created earlier)

Then, the user created using the membership API will be associated with the applicationid, so that the applicationname (and in turn the applicationname) can be found ). [This aims to allow multiple applications and sites to use the same database ]. Open the aspnet_users table and you can see these.

If you configure this program to run in the/website8 virtual directory, everything will be fine. However, if it is copied to another place or server and replaced with a virtual path (for example, "/app1" or, when membership APIS is used, they "cannot see" existing users in the database-because they will use a different applicationname to search for users in the database, filter users in the application_users table accordingly. This is why the above error occurs.

How to solve this problem:
The simplest way is to open the aspnet_users and aspnet_application tables in the aspnetdb database and "Think back" (figure out, because we may have forgotten the name of our virtual directory at that time) program name when creating users and other data (search in the aspnet_application table)

Then open your web. in the config file, add an applicationname attribute to the place where the provider declares and assign values to it. For example, the following code sets it to/website8 in the aspnet_application table:

<Membership>

<Providers>

<Clear/>

<Add name = "aspnetsqlmembershipprovider"

Type = "system. Web. Security. sqlmembershipprovider, system. Web, version = 2.0.0.0, culture = neutral, publickeytoken = b03f5f7f11d50a3a"

Connectionstringname = "localsqlserver"

Enablepasswordretrieval = "false"

Enablepasswordreset = "true"

Requiresquestionandanswer = "true"

Requiresuniqueemail = "false"

Passwordformat = "hashed"

Maxinvalidpasswordattempts = "5"

Minrequiredpasswordlength = "7"

Minrequirednonalphanumericcharacters = "1"

Passwordattemptwindow = "10"

Passwordstrengthregularexpression = ""

Applicationname = "/website8"

/>

</Providers>

</Membership>

In this way, the program can work normally, no matter which virtual directory we deploy this program.

Of course, we also need to ensure that the providers we configured will also be configured.

In this way, our program can work normally.

If you want to avoid it at the beginning:
The best way to avoid this problem is to always set the applicationname value. A better default value is "/".