How It Works
Besides adding and confi guring a few ASP.NET Server Controls, you didn’t do any coding in this exercise.
Still, you were able to implement a fully functional login procedure that enables a user to sign up
for an account and then log in to the site. So how does all this work? As you learned earlier, the ASP.
NET controls talk to the confi gured application service providers; a software layer that sits between the
login controls and the SQL Server database that keeps track of the users.
The very fi rst time you try to log in (or use other login controls that require database access), the
provider checks if your application is using a database with the necessary database objects, such as
tables. By default, it checks the database by looking at a connection string pointed to by the connectionStringName
attribute on the confi gured Membership provider. If the
database from the connection string doesn’t exist, or it doesn’t contain the
necessary tables, .NET executes a SQL script to prepare the database for
you. That is why there was a delay when you entered the username and
password in step 12. To fi nd out what the database looks like, go back to
VS, expand the App_Data folder, and then double-click your PlanetWrox.
mdf database. This opens the Database Explorer and shows your database.
Expand the Tables node to see which database objects have been added for
you, as shown in Figure 16-7.
After this database has been created successfully, the login controls
can use it. For example, when you create a new account using the
CreateUserWizard control, records are inserted in the Memberships and
Users tables. Similarly, when you try to log in, your username and password
are checked against these tables.
To force the ASP.NET run time to use forms-based authentication (which the confi gured Membership
provider uses under the hood), you need to set the mode attribute of the authentication element to
Forms in the Web.config fi le: