A Boolean value that indicates whether cookie caching is used. The default value is ". The path attribute enables a developer to limit the scope of a cookie to a particular directory hierarchy. The allowable values are: All the default ; Encryption; None; and Validation.
Refer back to Step 3 of the Forms Authentication Configuration and Advanced Topics tutorial for more information on these protection levels.
The default value is false. This value is only pertinent when createPersistentCookie is set to true. The default value is If false the default , a session cookie is used, which is deleted when the browser is closed. If true, a persistent cookie is used; it expires cookieTimeout number of minutes after it has been created or after the previous visit, depending on the value of cookieSlidingExpiration.
The default value is an empty string, which causes the browser to use the domain from which it was issued such as www. In this case, the cookie will not be sent when making requests to subdomains, such as admin. If you want the cookie to be passed to all subdomains you need to customize the domain attribute, setting it to "yourdomain.
The default is The RoleManagerModule does not create a cookie for users that belong to more than maxCachedResults roles. The reason maxCachedResults exists is because many user agents do not permit cookies larger than 4, bytes.
So this cap is meant to reduce the likelihood of exceeding this size limitation. If you have extremely long role names, you may want to consider specifying a smaller maxCachedResults value; contrariwise, if you have extremely short role names, you can probably increase this value.
By setting cacheRolesInCookie to true, the RoleManagerModule will now automatically cache the user's roles in a cookie rather than having to lookup the user's role information on each request. I explicitly set the createPersistentCookie and cookieProtection attributes to false and All, respectively. Technically, I didn't need to specify values for these attributes since I just assigned them to their default values, but I put them here to make it explicitly clear that I am not using persistent cookies and that the cookie is both encrypted and validated.
That's all there is to it! Henceforth, the Roles framework will cache the users' roles in cookies. If the user's browser does not support cookies, or if their cookies are deleted or lost, somehow, it's no big deal — the RolePrincipal object will simply use the Roles class in the case that no cookie or an invalid or expired one is available. Since possession of the role cache cookie is sufficient to prove role membership, if a hacker can somehow gain access to a valid user's cookie he can impersonate that user.
The likelihood of this happening increases if the cookie is persisted on the user's browser. For more information on this security recommendation, as well as other security concerns, refer to the Security Question List for ASP. The URL authorization rules are spelled out in Web. A particular role A comma-delimited list of roles For example, the URL authorization rules grant access to those users in the Administrators and Supervisors roles, but deny access to all others: Let's configure our application so that the ManageRoles.
To accomplish this, start by adding a Web. NET resources in the Roles directory. After saving your changes to Web. The UrlAuthorizationModule will detect that you do not have permission to visit the requested resource; consequently, the FormsAuthenticationModule will redirect you to the login page.
The login page will then redirect you to the UnauthorizedAccess. This final redirect from the login page to UnauthorizedAccess. In particular, the login page automatically redirects any authenticated user to UnauthorizedAccess. Now you should be able to view the three protected pages. If no match is found, the user is granted access. Limiting Functionality Based On the Currently Logged In User's Roles URL authorization makes it easy to specify coarse authorization rules that state what identities are permitted and which ones are denied from viewing a particular page or all pages in a folder and its subfolders.
However, in certain cases we may want to allow all users to visit a page, but limit the page's functionality based on the visiting user's roles. This may entail showing or hiding data based on the user's role, or offering additional functionality to users that belong to a particular role.
Such fine grain role-based authorization rules can be implemented either declaratively or programmatically or through some combination of the two. In the next section we will see how to implement declarative fine grain authorization via the LoginView control. Following that, we will explore programmatic techniques. Before we can look at applying fine grain authorization rules, however, we first need to create a page whose functionality depends on the role of the user visiting it.
Let's create a page that lists all of the user accounts in the system in a GridView. The GridView will include each user's username, email address, last login date, and comments about the user.
In addition to displaying each user's information, the GridView will include edit and delete capabilities. We will initially create this page with the edit and delete functionality available to all users.
In the "Using the LoginView Control" and "Programmatically Limiting Functionality" sections we will see how to enable or disable these features based on the visiting user's role. NET page we are about to build uses a GridView control to display the user accounts.
Since this tutorial series focuses on forms authentication, authorization, user accounts, and roles, I do not want to spend too much time discussing the inner workings of the GridView control. While this tutorial provides specific step-by-step instructions for setting up this page, it does not delve into the details of why certain choices were made, or what effect particular properties have on the rendered output.
Start by opening the RoleBasedAuthorization. In a moment we will write code that calls the Membership. Before we write the code that binds the user accounts to the grid, let's first define the GridView's fields.
From here, uncheck the "Auto-generate fields" checkbox in the lower left corner. This field will not be editable, so set its ReadOnly property to True. Let's format the output of this BoundField so that just the date is displayed instead of the date and time. Also set the ReadOnly property to True.
Add a Label Web control to each of the ItemTemplate s and bind their Text properties to the Email and Comment properties, respectively. Set the TextBox's Columns and Rows properties to 40 and 4, respectively, and then bind its Text property to the Comment property using two-way databinding. After configuring these TemplateFields, their declarative markup should look similar to the following: With these settings, the ValidationSummary will display a client-side alert if the user attempts to edit a user account with a missing or invalid email address.
Our next task is to bind the set of user accounts to the GridView. As Figure 7 shows, you should see a GridView listing information about each user account in the system. This simple grid interface is not suitable for scenarios where there are several dozen or more users. One option is to configure the GridView to enable paging. GetAllUsers method has two overloads: The second overload can be used to more efficiently page through the users since it returns just the precise subset of user accounts rather than all of them.
If you have thousands of user accounts, you might want to consider a filter-based interface, one that only shows those users whose UserName begins with a selected character, for instance. FindUsersByName method is ideal for building a filter-based user interface. We will look at building such an interface in a future tutorial. The GridView control offers built-in editing and deleting support when the control is bound to a properly configured data source control, such as the SqlDataSource or ObjectDataSource.
The UserGrid GridView, however, has its data programmatically bound; therefore, we must write code to perform these two tasks. The interesting stuff happens in the RowUpdating event handler. This event handler starts by ensuring that the data is valid and then grabs the UserName value of the edited user account from the DataKeys collection. Their Text properties contain the edited email address and comment.
In order to update a user account through the Membership API we need to first get the user's information, which we do via a call to Membership. The returned MembershipUser object's Email and Comment properties are then updated with the values entered into the two TextBoxes from the editing interface. Finally, these modifications are saved with a call to Membership. The RowUpdating event handler completes by reverting the GridView to its pre-editing interface.
Next, create the RowDeleting event handler and then add the following code: The DeleteUser method deletes the user account from the system, including related membership data such as what roles this user belongs to.
After deleting the user, the grid's EditIndex is set to -1 in case the user clicked Delete while another row was in edit mode and the BindUserGrid method is called. Note The Delete button does not require any sort of confirmation from the user before deleting the user account. I encourage you to add some form of user confirmation to lessen the chance of an account being accidentally deleted.
One of the easiest ways to confirm an action is through a client-side confirm dialog box. Verify that this page functions as expected. You should be able to edit any user's email address and comment, as well as delete any user account. Let's update this page so that only users in the Supervisors and Administrators roles can edit a user's email address and comment, and only Administrators can delete a user account. The "Using the LoginView Control" section looks at using the LoginView control to show instructions specific to the user's role.
If a person in the Administrators role visits this page, we will show instructions on how to edit and delete users. If a user in the Supervisors role reaches this page, we will show instructions on editing users. And if the visitor is anonymous or is not in either the Supervisors or Administrators role, we will display a message explaining that they cannot edit or delete user account information.
In the "Programmatically Limiting Functionality" section we will write code that programmatically shows or hides the Edit and Delete buttons based on the user's role. Using the LoginView Control As we've seen in past tutorials, the LoginView control is useful for displaying different interfaces for authenticated and anonymous users, but the LoginView control can also be used to display different markup based on the user's roles.