Programming Microsoft ASP.NET 4 - Dino Esposito [156]
Figure 7-6. The ASP.NET Web Site Administration Tool.
You can use this tool to create a default database to store profile data. The default database is a SQL Server file named aspnetdb.mdf, which is located in the App_Data special folder of the ASP.NET application. A proper connection string is added to the configuration file to be consumed by various ASP.NET provider-based frameworks. By default, the application will use it as a plain file through SQL Server Express. However, if you decide to host it in a full installation of SQL Server, all you need to do is update the connection string in the web.config file of your application.
The tables and schema of the database are fixed. Note that the same database—the aspnetdb.mdf file—contains tables to hold user profiles and also membership and role information. The use of a membership database with users and roles is important because personalization is designed to be user-specific and because a user ID—either a local Windows account or an application-specific logon—is necessary to index data.
Profile data has no predefined duration and is permanently stored. It is up to the Web site administrator to delete the information when convenient.
As mentioned, WSAT is not necessarily the way to go; it’s just one option for setting up the profile infrastructure. For example, if you’re using a custom provider, the setup of your application is responsible for preparing any required storage infrastructure—be it a SQL Server table, an Oracle database, or whatever else. We’ll cover the setup of profile providers in the next section.
Note
At this point, many developers start thinking that they probably don’t want to be bound to aspnetdb.mdf because it’s a general purpose tool or because it’s too generic of a repository for their data. So, many developers decide to plan to build a tailor-made custom provider and run their own solution.
Building custom providers is doable and fully supported by the framework. However, make sure that building such a provider doesn’t turn out to be simply an extra (and avoidable) pain in the proverbial neck. The aspnetdb.mdf solution is effective and free, and it provides zero cost of ownership. After you have hosted it in a SQL Server installation, you have the full power of management tools at your disposal. And, by the way, although you can reasonably consider renaming the database on a per-application basis, the database (and the related ASP.NET API) is designed to support multiple applications. In other words, you can even have a single instance of aspnetdb also in a hosting scenario.
Personally, I don’t mind using aspnetdb when I need profile support. Membership and role management, though, might be a different story.
Working with Anonymous Users
Although user profiles are designed primarily for authenticated users, anonymous users can also store profile data. In this case, though, a few extra requirements must be fulfilled. In particular, you have to turn on the anonymousIdentification feature, which is disabled by default:
The purpose of anonymous user identification is to assign a unique identity to users who are not authenticated and recognize and treat all of them as an additional registered user.
Note
Anonymous identification in no way affects the identity of the account that is processing the request. Nor does it affect any other aspects of security and user authentication. Anonymous identification is simply a way to give a “regular” ID to unauthenticated users so that they can be tracked as authenticated, “regular” users.
In addition, to support anonymous identification you must mark properties in the data model with the special Boolean attribute named allowAnonymous. Properties not marked with the attribute are not made available to anonymous users.