Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 6 11 Oct 2006 00:00 GMT| A Multipart Series on ASP.NET 2.0's Membership, Roles, and Profile |
|---|
This article is one in a series of articles on ASP.NET 2.0's membership, roles, and profile functionality.
|
Part 1 - learn about how the membership features
make providing user accounts on your website a breeze. This article covers the basics of membership, including why it is needed,
along with a look at the SqlMembershipProvider and the security Web controls.Part 2 - master how to create roles and
assign users to roles. This article shows how to setup roles, using role-based authorization, and displaying output on
a page depending upon the visitor's roles.Part 3 - see how to add the membership-related
schemas to an existing database using the ASP.NET SQL Server Registration Tool (aspnet_regsql.exe).Part 4 - improve the login experience by
showing more informative messages for users who log on with invalid credentials; also, see how to keep a log of invalid
login attempts.Part 5 - learn how to customize the Login control.
Adjust its appearance using properties and templates; customize the authentication logic to include a CAPTCHA.Part 6 - capture additional user-specific
information using the Profile system. Learn about the built-in SqlProfileProvider.
(Subscribe to this Article Series!
)
The Membership API in the .NET Framework provides the concept of a user account and associates with it core properties:
username, passsword, email, security question and answer, whether or not the account has been approved, whether or not the
user is locked out of the system, and so on. However, depending on the application's needs, chances are your application
needs to store additional, user-specific fields. For example, an online messageboard site might want to also allow users
to specify a signature, their homepage URL, and their IM address.
There are two ways to associate additional information with user accounts when using the Membership model. The first - which
affords the greatest flexibility, but requires the most upfront effort - is to create a custom data store for this information.
If you are using the SqlMembershipProvider, this would mean creating an additional database table that had as a primary key
the UserId value from the aspnet_Users table and columns for each of the additional user properties.
In the online messageboard example, the table might be called forums_UserProfile and have columns like
UserId (a primary key and a foreign key back to aspnet_Users.UserId), HomepageUrl,
Signature, and IMAddress.
Rather than using custom data stores, the ASP.NET 2.0 Profile system can be used to store user-specific information.
The Profile system allows the page developer to define the properties she wants to associate with each user. Once defined,
the developer can programmatically read from and assign values to these properties. The Profile system accesses or writes
the property values to a backing store as needed. Like Membership and Roles, the Profile system is based on the
provider model, and the particular Profile provider
is responsible for serializing and deserializing the property values to some data store. The .NET Framework ships with
a SqlProfileProvider
class by default, which uses a SQL Server database table (aspnet_Profile) as its backing store.
In this article we will examine the Profile system - how to define the user-specific properties and interact with them
programmatically from an ASP.NET page - as well as look at using the SqlProfileProvider that ships with
.NET 2.0. In a future article we'll look at how to create and use a custom profile provider. Read on to learn more!
Read More >
Source: 4GuysFromRolla Survey Exposes the Four Web Dev Stereotypes - Which are You? 04 Oct 2006 07:14 GMTIn what may be the largest survey of web developers ever, The State of Web Development 2006/2007 exposes four key web professional stereotypes. In this review, Nick explains how the stats were collated, and what they revealed about the industry and those who work in it.
Source: SitePoint