Administering an ASP.NET Application
Administering an ASP.NET Application
In addition to working pages, well-done graphics, and back-end services and components, a real-world Web application also requires a set of administrative tools to manage users, security, and configuration. In most cases, these tools consist of a passable and quickly arranged user interface built around a bunch of database tables; application developers are ultimately responsible for building them. To save time, these tools are often created as Windows Forms applications. If the application is properly designed, some business and data access objects created for the site can be reused. Are these external and additional applications always necessary?
While an ad hoc set of utility applications might be desired in some cases, having an integrated, rich, and further customizable tool built into Visual Studio .NET would probably be helpful and sufficient in many cases. In Visual Studio .NET 2005, you find available a whole Web application to administer various aspects of the site. The application, known as the Web Site Administration Tool (WSAT), is available through the Web site menu (or the Solution Explorer toolbar) and is extensively based on the ASP.NET provider model.
The Web Site Administration Tool
Figure 2-26 presents the administration tool in its full splendor. The tool is articulated in four blocks (plus the home), each covering a particular area of administration membership, user profiles, application settings, and providers.
Figure 2-26: The Visual Studio .NET 2005 ASP.NET Administration Tool.
As mentioned, WSAT is a distinct application that the ASP.NET 2.0 setup installs with full source. You find it under the ASP.NETWebAdminFiles directory, below the ASP.NET build installation path. This path is:
%WINDOWS%\Microsoft.NET\Framework\[version]\CONFIG\Browsers
You can also run the tool from outside Visual Studio .NET 2005. In this case, though, you must indicate a parameter to select the application to configure. Here's the complete URL to type in the browser's address bar for an application named ProAspNet20.
http://localhost:XXXX/asp.netwebadminfiles/default.aspx?applicationUrl=/ProAspNet20
The XXXX indicates the port used by the local Web server. The WSAT application, in fact, is not publicly exposed through IIS for obvious security reasons. Table 2-3 details what you can expect to do with the tool.
| Configuration Tab | Description |
|---|---|
| Security | Enables you to set up and edit users, roles, and access permissions for your site |
| Application | Enables you to manage your application's configuration settings, such as debugging and SMTP options |
| Provider | Enables you to select the provider to use for each ASP.NET feature that supports providers |
Membership and Role Management
The Security tab of WSAT lets you manage all the security settings for your application. You can choose the authentication method, set up users and passwords, create roles and groups of users, and create rules for controlling access to specific parts of your application. A wizard will guide you throught the steps needed to set up individual users and roles. By default, membership and roles information are stored in a local SQL Server database (aspnetdb.mdf) stored in the App_Data folder of your Web site. If you want to store user information in a different storage medium, use the Provider tab to select a different provider.
In ASP.NET 1.1, it is fairly common to have a custom database store credentials for authorized users. The point is that this database must be filled out at some time; in addition, the site administrator must be able to manage users and especially roles. In ASP.NET 1.1, you have a few options: charge your developers with this additional task, be charged by external consultants with this extra cost, or buy a third-party product. If you can find the product that suits you to perfection in terms of functionalities and costs, you're probably better off buying this instead of building code yourself. With homebrew code, you end up with a smaller set of features, often renounce the implementation of important security guidelines (for example, force password change every n days), and usually spend at least as much money, if not more, for a system with less capabilities and likely less reliability.
On the other hand, a WSAT-like tool doesn't sound like a mission-impossible task. However, it is the kind of cost that you might cut out of your budget. Finding a WSAT-like tool integrated in the development environment sounds like the perfect fit. It lets you accomplish basic administration tasks at no extra cost; and if you need more features, you can always turn to third-party products or, because you have the source code, you can inject your own extensions quite seamlessly.
Application Settings Management
Sometimes ASP.NET applications consume information (UI settings, favorites, general preferences, and connection strings) that you don't want to hard-code into pages. While applications can work out their own solutions for keeping data as configurable as possible (for example, databases or XML files), still the <appSettings> section in the web.config file provides an easy way out. The <appSettings> section, in fact, is specifically designed to store application-specific settings that can be expressed in a simple name/value fashion. The WSAT Application tab provides a convenient way to edit this section and create or edit entries.
As you can see in Figure 2-27, you can use the Application tab also to set debugging/tracing options and manage SMTP settings. In particular, mail settings determine how your Web application sends e-mail. If your e-mail server requires you to log on before you can send messages, you'll use the page to specify the type of authentication that the server requires, and if necessary, any required credentials.
Figure 2-27: The Application tab in the Web Site Administration Tool.
