Last Updated:
-
Examining ASP.NET's Membership, Roles, and Profile - Part 13
ASP.NET's forms-based authentication system in tandem with the Membership API and Login Web controls make it a cinch to create a user store, create
user accounts, and allow visitors to log into the site. What's more, with little effort it's possible to define roles, associate user accounts with
roles, and determine what functionality is available based on the currently logged in user's role (see Part
2). Many ASP.NET sites that use Membership have an Admin role, and users in that role are granted certain functionality not available to non-Admin users.
Consider an online store - Admin users might be able to manage inventory, whereas the only way normal members could interact with the inventory was
by adding items to their shopping cart.
I was recently working with a client who had an interesting request: he needed the ability for Admin users to be able to log into the site
as another user, and perform actions as if that other person had logged in herself. Returning to the online store example, imagine that some customers
periodically phone in their order, or mail or fax in an order form. An Admin, receiving this order, could then log into the site as that customer
and place the order on the customer's behalf.
This article shows how to allow an Admin user to log into a Membership-based website as another user, and includes a complete working demo available
for download at the end of the article. Read on to learn more!
-
Examining ASP.NET's Membership, Roles, and Profile - Part 12
Several of the earlier installments in this article series examined how to apply authorization rules in order to prohibit particular users, roles,
or classes of users from accessing particular resources. For instance, Part 2
showed how to define URL-based authorization rules in web.config for roles. With just a bit of XML markup, it is possible to block particular users
or roles from visiting certain web pages. Just installments also looked at using the LoginView control, which displays different markup based on whether
the user is authenticated or not (and can also be used to display different markup based on the currently logged in user's role).
There are also programmatic techniques you can use to determine the identity of the currently logged on user and what roles she belongs to.
The URL-based authorization, LoginView control, and programmatic techniques can be used in tandem to ensure that a user does not visit a page or
perform some operation if she is not authorized. But what if you forget to implement one of these safeguards? For example, imagine that you have a web
page that includes a button that, when clicked, perform some task that is only intended for administrators. You could put this button in a LoginView
control or you could use programmatic techniques to ensure that only users in the appropriate role (say, Admin) saw the button. But what if
sometime later you, or another developer, removed this check by accident? The net result would be that any user visiting the page could perform the
administrator-only operation! Whoops!
To reduce the likelihood of such security mishaps, the .NET Framework includes capabilities for declaratively asserting permissions (via attributes) on
methods and classes. In a nutshell, you can add such attributes to ASP.NET pages, their code-behind classes, and your business logic and data access layers.
With these attributes in place, your visitors will be barred from performing unauthorized actions, regardless of whether there are any security holes in the
user interface. Read on to learn more!
-
Examining ASP.NET's Membership, Roles, and Profile - Part 11
Many websites that support user account allow anyone to create a new account, but require new users to undergo some form of verification before their
account is activated. A common approach is to send an email to the newly created user with a link that, when visited, activates their account. This
approach ensures that the email address entered by the user is valid (since it is sent to that user's email address). This workflow not only ensures the
valid data entry, but also helps deter automated spam bots and abusive users.
In past installments of this article series we've seen how to use the CreateUserWizard control to allow users to create new accounts. By default, the
user accounts created by the CreateUserWizard control are activated; new users can login immediately and start interacting with the site. This default
behavior can be customized, however, so that new accounts are disabled. A disabled user cannot log into the site; therefore, there needs to be some manner
by which a newly created user can have her account enabled.
There are many ways by which an account may be activated. You could have each account manually verified by an administrative user. If your site requires
users to pay some sort of monthly fee or annual due, you could have the account approved once the payment was successfully processed. As aforementioned,
one very common approach is to require the user to visit a link sent to the email address they entered when logging on.
This article explores this latter technique. Read on to learn more!
-
Examining ASP.NET's Membership, Roles, and Profile - Part 10
The Membership system automatically tracks the last
date and time each user's account has been accessed. With the SqlMembershipProvider, this information is
stored in the aspnet_Users database table in a datetime column named LastActivityDate. This
column is automatically updated to the current UTC date and time whenever a user
logs into the site, whenever their user account information is updated, and whenever their user account information is retrieved.
In addition to tracking each user's last activity date and time, the Membership system includes a method named
GetNumberOfUsersOnline.
This method returns the number of users whose last activity date and time is within a specified window; by default, this method returns the number of
users whose aspnet_Users.LastActivityDate value falls within the last 15 minutes.
This article, the tenth installment of a multipart article series on ASP.NET's Membership, Roles, and Profile systems, examines
the GetNumberOfUsersOnline method and see how to extend the Membership system to include additional user
activity information. Specifically, we will add a new table to the database used by the SqlMembershipProvider that associates a description
of each user's current action. We will then update our ASP.NET pages to update the records in this table to include a description of the user's
current action. For example, when visiting the home page we may use the description, "Viewing the home page." Finally, we will create a web page that displays
the list of currently logged on users and their last known action. Read on to learn more!
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 9
ASP.NET 2.0's Membership, Roles, and Profile systems were designed using the provider model, which
enables these systems to seamlessly use different implementations. ASP.NET ships with a provider for managing members and roles through SQL Server and another for using
Active Directory. It is also possible to plug in other implementations that have been built from the ground up or downloaded from other sources. For example, you can download
alternative providers from Microsoft that store membership and role information in a Microsoft Access database (see
Part 8 of this article series). Most of the articles in this series, however, have focused on using the
SQL Server provider (SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider). The SQL Server providers are typically
the provider of choice for Internet-based web applications, whereas the Active Directory providers are more commonly used in intranet scenarios.
The SQL Server providers create a number of tables, views, and stored procedures in the specified SQL Server database. Therefore when using these providers it is possible
to add, modify, or delete membership or roles or profile-related data through T-SQL statements. In this article we'll look at a common membership need - deleting users.
While users can certainly be deleted through the .NET Membership API, there are scenarios where it may be much easier to use a T-SQL script. However, bypassing the
managed APIs and working directly with the database is not without its own host of challenges. By the end of this article we'll have addressed these issues, discussed the
pros and cons of using T-SQL in lieu of the managed APIs, and have examined both the managed API methods and T-SQL commands for deleting a single user and deleting
all users. Read on to learn more!
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 8
One of the main challenges of building a programming framework is balancing the desires to create a standardized, straightforward
API for accomplishing common tasks and providing flexibility and customizability so that developers using the framework can
mold the framework to fit their applications rather than having to bend their applications to fit the framework. With the .NET
Framework 2.0, Microsoft implemented this delicate balance with the provider
model. The provider model allows for a standardized API to be defined within the framework, but enables developers
to design their own concrete implementation and plug that implementation into their systems at runtime. In
Part 7 of this article series we saw how the Membership,
Roles, and Provider pieces examined throughout this series all utilize the provider model. Moreover, in Part 7 we created
a custom XML provider for the Profile system.
I recently worked on a website that primarily contained static content. The client, however, had a particular page that
needed to display data from a simple database with just one table. Additionally, a web page was needed to allow a set of
administrators to add, update, and delete data from this table. With ASP.NET 2.0's data source controls and Membership system,
this functionality is typically a breeze, but there was a catch - the web hosting company didn't support SQL Server databases,
so Microsoft Access databases needed to be used instead. The challenge here is that the .NET Framework BCL only contains a
Membership provider for Microsoft SQL Server.
Fortunately, Microsoft provides an Access database template and providers for using Membership, Roles, and Profile with
Access. In this article, we'll look at how to get these Access-based providers and how to use the provider in an ASP.NET
2.0 web application. Read on to learn more!
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 7
One of the main challenges of building a programming framework is balancing the desires to create a standardized, straightforward
API for accomplishing common tasks and providing flexibility and customizability so that developers using the framework can
mold the framework to fit their applications rather than having to bend their applications to fit the framework. With the .NET
Framework 2.0, Microsoft implemented this delicate balance with the provider
model. The provider model allows for a standardized API to be defined within the framework, but enables developers
to design their own concrete implementation and plug that implementation into their systems at runtime. (See
A Look at ASP.NET 2.0's Provider Model for more details
on the provider model, its implementation in ASP.NET 2.0, and the concepts
behind it.)
The Membership, Roles, and Provider pieces examined throughout this article series all utilize the provider model. Throughout the past
six installments of this article series we've examined some of the providers that ship with the .NET Framework (such as
SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider). In fact, you can
download the source code for these built-in providers from Microsoft as well as a Provider Toolkit for creating your own
custom providers [link]. And Scott
Guthrie lists a number of custom Membership, Roles, and Profile providers in his ASP.NET
2.0 Membership, Roles, Forms Authentication, and Security Resources page.
If the none of the built-in providers meet your needs, you can always create your own custom providers. Custom providers are
useful when integrating legacy systems (perhaps you have an old Users database table that differs from the
database tables used by SqlMembershipProvider) or when needing to persist membership, role, or provider information
in a backing store not natively supported by one of the built-in providers.
In this article, we'll discuss the concepts behind creating and using a custom provider and then implement a simple custom
profile provider that serializes profile information to XML files. Read on to learn more!
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 6
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!
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 5
ASP.NET 2.0 makes it quite easy to accomplish common tasks. Want to display data from a database, allowing the user to sort,
edit, delete, and page through that data? Simply add and configure a SqlDataSource on the page, bind it to a GridView, check
a few checkboxes in the GridView's smart tag, and, voila, you have a web-based data entry form that can be created in 15 minutes or
so. While the simple case is often a cinch to implement, in the real world rarely is the simple case a practical solution.
Often, the simple case needs to be extended and expanded and customized to fit custom rules, logic, formatting, and behavior.
Thankfully, ASP.NET 2.0 was designed with extensibility in mind and, thanks to things like the
provider model, event handlers, and templates, customizing
and extending the simple case is both doable and usually doable without an inordinate amount of effort or "hackery."
As we've seen throughout this article series, ASP.NET 2.0 provides a platform for creating and managing user accounts
through its membership, roles, and profile systems. The related Web controls - Login, LoginView, CreateUserWizard, LoginStatus, and so
on - can be used to achieve the simple case. Need to provide an interface for logging on a user? Simply drop the Login Web
control onto a page. But what if we want to customize the login experience? We may want to reposition the
Web controls used by the Login control or add additional content or Web controls to the Login control interface. Or we may want to
customize the credentials supplied by the user for authentication purposes. Rather than requiring just their username and
password, what if we want to also make them supply their email address on file? Or perhaps we want to include a
CAPTCHA (those boxes with text in an image designed to defeat robot
programs from successfully submitting a form).
The Login Web control can be customized in a number of ways. First, it has a bevy of properties that can adjust whether
or not the "Remember me next time" checkbox is displayed, the text displayed for the "Log In" Button, the colors, fonts, and
other style-related settings, and so on. For further control over the layout of the Login control or of the actual controls
that makeup the Login control, we can convert the control into a template. And finally, the control's authentication logic can
be customized by creating an event handler for the Authenticate event
(which can allow us, for example, to use a CAPTCHA as part of the authentication process).
In this article we'll examine how to customize the Login control through its properties, through templates, and by performing
custom authentication through an Authentication event handler (including an example with a CAPTCHA). Read on to learn more!
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 4
The ASP.NET 2.0 Membership class
provides a ValidateUser(userName, password) method
that returns a Boolean value indicating whether or not a user's supplied credentials are valid. This method is automatically utilized
from the Login Web control and
can also be used programmatically, if needed. In the Membership system, there are multiple scenarios by which a user's credentials
can be invalid:
- The username supplied might not exist in the membership directory
- The username may exist, but the supplied password might be incorrect
- The username and password may be correct, but:
- The user may not yet be approved
- The user may be locked out; this can happen if the user attempts to login with an invalid password for
a specified number of tries (five, by default)
Unfortunately, the ValidateUser(userName, password) method just returns False if the credentials
are invalid, and does not include information as to why, exactly, the credentials are invalid. For the Login control, when
ValidateUser(userName, password) returns False the message, "Your login attempt was not successful. Please try again."
is displayed, by default. If a user is locked out or their account not yet approved, such a message - which will be shown even in
the face of the correct username and password - can easily lead to a confused and frustrated user.
In this article we'll see how to provide additional feedback during the login process to help alleviate any such confusion.
Moreover, we'll see how to audit invalid logins and present the data in a report. Read on to learn more!
Read More >
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 3
The membership and roles providers used by ASP.NET by default are the SqlMembershipProvider and SqlRoleProvider,
respectively, which serialize membership and roles information to a SQL Server database. Specifically, this information is stored
in a variety of pre-defined tables and accessed through a number of pre-defined stored
procedures. In order to use membership or roles with your application using the default providers you need to apply this
pre-defined schema to your application's database.
If you don't already have a database, ASP.NET will happily create a SQL Server 2005 Express Edition database in your application's
App_Data folder that contains the necessary schema. While this is certainly handy, often developers are faced with
a situation where they want to add ASP.NET 2.0's membership and roles features to an existing data model. For example, you may
have an application that hasn't yet needed membership or roles services, but recent feature requests may require that certain
areas of the site are available only to particular users, or certain functionality is limited to those who belong to a specific
role. In any case, adding membership and roles support to an existing database can be accomplished through the
ASP.NET SQL Server Registration Tool (aspnet_regsql.exe).
In this article we'll examine how to use this tool to apply the membership and roles services for the SqlMembershipProvider and SqlRoleProvider
providers. This tool can be used both from the command-line and through the graphical wizard. Furthermore, we'll pay special attention
on how to use this tool with an existing SQL Server 2005 Express Edition database in the App_Data folder, which
can be a particularly challenging task. Read on to learn more!
Read More >
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 2
In Part 1 of this article series we saw how
ASP.NET 2.0's membership service provides a framework for managing user accounts. The framework is composed of a
Membership class with a bevy of methods that can be used to create, delete, modify, retrieve, and authenticate
users. Since every developer's needs are different, a concrete membership framework would be virtually useless except for
new, simple projects. Thankfully the Membership class is designed using the provider model, meaning
that the membership framework's actual implementation can be customized. ASP.NET ships with two membership providers -
SqlMembershipProvider and ActiveDirectoryMembershipProvider - and you can build your own, if needed.
Many websites that provide user accounts need to group users in various roles. The roles a user belongs might
specify what web pages they have access to, what information they see on the screen, and whether or not certain regions in
a page are editable or view-only. Grouping users into roles and basing functionality and authorization based on a user's
role is quite easy in ASP.NET 2.0 thanks to the roles service.
Like the membership service, the roles service defines a framework for programmatically creating and deleting roles,
assigning and removing roles from users, and determining what users belong to a role, and to what roles a user belongs.
In this article we will examine ASP.NET 2.0's role service. We'll start by seeing how to setup and configure the roles service
on a website, along with how to base authorization rules using roles. In addition, we'll look at how to programmatically
work with the roles service, and see how to use the LoginView Web control to show information based on the logged in user's role.
Read on to learn more!
Read More >
-
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 1
There's one thing messageboard websites, eCommerce websites, social network
websites, and portal websites share in common: they all provide user accounts. These websites, and many others, allow
(or require) visitors to create an account in order to utilize certain functionality. For example, a messageboard website, like
ASPMessageboard.com, allows anonymous and authenticated visitors to view and search
the posts in the various forums. However, in order to be able to post a new thread or reply to a message a visitor must have an
account and must log into the site.
Providing user account support for a site involves the same set of steps: creating a database table to store user account information,
creating a login page, defining a system by which authenticated users' logged on status is remembered across postbacks, specifying
which pages are only available for authenticated users (authorization), creating a page for visitors to create a new user account,
creating a page for the site's administrators to manage the user accounts, and so forth. Prior to ASP.NET, developers had to decide
how to implement all of these facets on their own. ASP.NET introduced the concept of forms-based authentication, which
provided a FormsAuthentication class to ease signing in and out of a site, as well as a protected authentication
ticket to remember users' logged on status across page requests. (See Simple
Authentication for an article on implementing authentication with classic ASP; refer to Using
Forms Authentication in ASP.NET and Dissecting Forms Authentication
for more information on ASP.NET's forms-based authentication capabilities.)
Even with forms-based authentication, though, ASP.NET developers are still on the hook for defining and creating the structure for storing
user account information, for creating login and logout web pages, for enabling visitors to create new accounts and administrators
to manage accounts, and so on. Thankfully ASP.NET version 2.0 has lightened developers' loads by providing the
membership system and the security Web controls in ASP.NET 2.0. In a nutshell, membership is an API that provides
programmatic access to common user account-related tasks. For example, there are methods to create a new user account, authenticate
a user's credentials, delete a user, return all user information in the site, and so on. Furthermore, there are a number of security
Web controls built atop this API that make performing common user account tasks as simple as dragging and dropping a control
on the page.
In this article series we will be examining the ins and outs of version 2.0's membership, roles, and pofile systems and the various security Web controls.
This particular article will examine the basics of membership with a look at configuring and using the built-in SqlMembershipProvider.
As we will see, this particular provider stores user account information in a pre-defined database schema. Read on to learn more!
Read More >
|
