Getting Started with Membership


By far, the biggest new security feature in ASP.NET 2.0 is membership, which makes it easy to implement user accounts and get started authenticating your users using Forms authentication. To get things started quickly, we'll begin with a five-minute demo that you can follow along with if you are sitting in front of a computer.[3] This will quickly show you the power of membership and introduce you to some of the new login controls. Once you have a feel for what membership is all about, we'll drill down and show you the nuts and bolts so that you can squeeze the most out of it in your own applications.

[3] Note that for this demo we're using a machine with Visual Studio 2005 on which SQL Server 2005 is also installed. We've already run aspnet_regsql to create the ASP.NET membership database, as was described in Chapter 4.

After opening Visual Studio, we begin by creating a new Web application in a temporary file system folder. We add a web.config file and enable Forms authentication, and require that everyone log in by denying all anonymous requests (? is a wildcard that matches all anonymous requests), as shown in Listing 5-1.

Listing 5-1. web.config

<configuration>     <system.web>       <compilation defaultLanguage="C#"/>       <authentication mode="Forms" />       <authorization>         <deny users="?"/>       </authorization> </system.web> </configuration> 

We can then put together a default Web page using a couple of the membership controls that are new on the toolbar in Visual Studio 2005 (see Figure 5-1). We use the LoginName control to welcome the user by name, and the LoginStatus control to allow the user to log out when finished with the application. Listing 5-2 shows the code for this page.

Figure 5-1. Login controls in the toolbox


Listing 5-2. default.aspx

<html> <body> <form  runat="server">     <h1>Getting Started with Membership</h1>     <p>Welcome, <asp:LoginName  runat="server" /></p>     <p><asp:LoginStatus  runat="server" /></p> </form> </body> </html> 

Next, we create the simplest possible login form, using the new login control. By default, Forms authentication assumes the name of the login page is login.aspx, so that's what we name the login form, shown in Listing 5-3.

Listing 5-3. login.aspx

<html> <body> <form  runat="server">     <asp:Login  runat="server"/> </form> </body> </html> 

At this point, believe it or not, we've got a functioning Web application that authenticates its users with a form. But at the moment there are no users who are allowed to log in, so we need to populate the membership database for this application with some users. To do this, we'll use the built-in administration tool in Visual Studio via the Website | ASP.NET Configuration menu. This pops up a Web page with several options: we choose the Security tab and select Create User, at which point we can fill out a form to add a user (Alice, in Figure 5-2) to the membership database for the application.

Figure 5-2. Creating a new user


Once this new user is created, we can test the application. If we navigate to the default.aspx page, we are immediately redirected to the login page, where we can enter Alice's user name and password, as shown in Figure 5-3.

Figure 5-3. Logging in


After pressing the Log In button, we will be redirected back to the originally requested page, default.aspx, which welcomes the user by name and offers a way to log out, shown in Figure 5-4. If we press the Logout link, we are redirected back to the login page.

Figure 5-4. Logged in


It's a testament to the efficiency of ASP.NET 2.0 that we can build a full database-backed site with Forms authentication in so few steps. For most "real" Web applications, however, a more thorough understanding of each component we just used is necessary, both for possible customization and to know if your particular solution is "secure enough" as we discussed earlier. Let's start by tracking down how all of this "magic" happened. If you open machine.config, you'll see a new <membership> section that provides a number of default settings (see Listing 5-4). The default Membership provider is based on SQL Server, and there is a connectionStringName property that points to the <connectionStrings> section, where the default connection string uses integrated security to connect to the local SQL server instance using a database called ASPNETDB. This is the database that aspnet_regsql creates by default.

Listing 5-4. Machine.config

<connectionStrings>     <add name="LocalSqlServer"          connectionString="Integrated Security=SSPI;database=aspnetdb"          providerName="System.Data.SqlClient" /> </connectionStrings> <system.web>   <membership>     <providers>       <add name="AspNetSqlMembershipProvider"            type="System.Web.Security.SqlMembershipProvider, ..."            connectionStringName="LocalSqlServer"            enablePasswordRetrieval="false"            enablePasswordReset="true"            requiresQuestionAndAnswer="true"            applicationName="/"            requiresUniqueEmail="false"            passwordFormat="Hashed"            maxInvalidPasswordAttempts="5"            minRequiredPasswordLength="7"            minRequiredNonalphanumericCharacters="1"            passwordAttemptWindow="10"            passwordStrengthRegularExpression="" />     </providers>   </membership> </system.web> 

Note that if you're running as an administrator when you launch this Web application in Visual Studio, you'll have full permission to the membership database by default, and your demo will work smoothly. If you're running as a normal user[4] and try the same thing, you'll find that things don't work until you grant yourself permission to use the Membership features of the ASPNETDB database, as you'll see later in this chapter.

[4] Good for you! It's tough to run as a nonadmin, but there are lots of benefits, not the least of which is that you'll be safer from viruses and worms that threaten to install root kits, key loggers, and so on. For more information, check out items 8 and 9 in Keith's book at winsecguide.net, and also Aaron Margosis' list of articles on the topic at http://tinyurl.com/ge7f2.

If you drill into the ASPNETDB database, you'll see some tables that relate to the membership functionality being used here. The aspnet_ Applications table allows multiple Web applications to use a single database, which is convenient for people who give trade show demos on a regular basis, but in a production scenario you'll usually be better off giving your application its own private database, as opposed to sharing it with other applications that you might not trust. The aspnet_Users and aspnet_Membership tables store data for each user account, including details like the user's name, password verifier, e-mail address, and so on.

At this point you might be wondering exactly how the login controls interact with the database, but to understand that, you'll first need to see how the new provider architecture in ASP.NET 2.0 works.




Essential ASP. NET 2.0
Essential ASP.NET 2.0
ISBN: 0321237706
EAN: 2147483647
Year: 2006
Pages: 104

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net