Programming Microsoft ASP.NET 4 - Dino Esposito [421]
var customInfo = identity.Ticket.UserData;
var tokens = customInfo.Split('|');
// Build a richer principal object
var myPrincipal = new MyPrincipal(identity, roles)
{
CurrentTime = tokens[0],
Number = tokens[1]
};
// Store the new principal in the HttpContext
HttpContext.Current.User = myPrincipal;
}
Having done all of this, you can now cast the HttpContext.User object to your principal type (MyPrincipal in the example) and use the additional properties in any page. MyPrincipal is a plain class that inherits from GenericPrincipal:
public class MyPrincipal : GenericPrincipal
{
public MyPrincipal(IIdentity identity, String[] roles) :
base(identity, roles)
{ }
// Extra properties
public String CurrentTime { get; set; }
public String Number { get; set; }
}
The Membership and Role Management API
The membership API provides a set of classes to let you manage users and roles. Partnered with the FormsAuthentication class, the Membership and Roles classes form a complete security toolkit for ASP.NET developers. The Membership class supplies methods to manage user accounts—for adding or deleting a new user and editing any associated user information, such as the e-mail address and password. The Roles class creates and manages associations between users and roles.
What does the expression “managing user accounts” mean exactly? Simply put, it states that the Membership class knows how to create a new user or change his or her password. How do you create a user? Typically, you add a new record to some sort of data store. If that’s the case, who is in charge of deciding which data store to use and how to actually write the new user information? These tasks represent the core functionality the membership API is designed to provide.
The membership API doesn’t bind you to a fixed data store and data scheme. Quite the reverse, I’d say. It leaves you free to choose any data store and scheme you want, but it binds you to a fixed API through which users and roles are managed. The membership API is based on a provider model, and it delegates to the selected provider the implementation of all the features defined by the API itself. The provider component is only bound to implementing a contracted interface.
The Membership Class
Centered on the Membership static class, the membership API shields you from the details of how the credentials and other user information are retrieved and compared. The Membership class contains a few methods that you use to obtain a unique identity for each connected user. This information can also be used with other ASP.NET services, including role-based function enabling and personalization.
Among the members of the class are methods for creating, updating, and deleting users, but not methods for managing roles and programmatically setting what a user can and cannot do. For that, you have to turn to the Roles class, which we’ll cover later.
The Membership class defaults to a provider that stores user information in a SQL Express database in a predefined format. If you want to use a custom data store (such as a personal database), you can create your own provider and just plug it in.
The Programming Interface of the Membership Class
Table 19-8 lists the properties exposed by the Membership class.
Table 19-8. Properties of the Membership Class
Property
Description
ApplicationName
A string to identify the application. It defaults to the application’s root path.
EnablePasswordReset
Returns true if the provider supports password reset.
EnablePasswordRetrieval
Returns true if the provider supports password retrieval.
MaxInvalidPasswordAttempts
Returns the maximum number of invalid password attempts allowed before the user is locked out.
MinRequiredNonAlphanumericCharacters
Returns the minimum number of punctuation characters required in the password.
MinRequiredPasswordLength
Returns the minimum required length for a password.
PasswordAttemptWindow
Returns the number of minutes in which a maximum number of invalid password or password