Configuring the Role Manager and Provider


Like the Membership provider, a Role provider is simply a class that extends an abstract base class (in this case, RoleProvider). But in order to implement the optional cookie cache, ASP.NET also includes an HttpModule called RoleManagerModule. This module is wired into the pipeline by default, but it does nothing unless you enable it via web.config. Listing 5-10 is an example that does just that. (Note that just like <membership>, the <roleManager> element should be placed under <system.web>.)

Listing 5-10. RoleManager configuration

<roleManager enabled="true"              defaultProvider="MyRoleProvider"              cacheRolesInCookie="true"              maxCachedResults="25"              cookieName=".ASPXROLES"              cookiePath="/"              cookieTimeout="30"              cookieSlidingExpiration="true"              cookieRequireSSL="false"              cookieProtection="All"              createPersistentCookie="false"              domain="">   <providers>     <clear/>     <add name="MyRoleProvider"          type="System.Web.Security.SqlRoleProvider"          connectionStringName="aspnetdb"          applicationName="MyApplication"/>   </providers> </roleManager> 

The first thing Listing 5-10 does is "turn on" the RoleManagerModule by setting enabled="true". I've configured a default Role provider, and defined it in the <providers> section. Note that the provider specifies an application name and a connection string, just like with Membership. It's important that these values be the same for both your Membership provider and your Role provider if you're using the SQL providers.

The rest of the role manager configuration is all about cookie caching, so you only need to worry about these settings if you're going to use that feature. The first thing I've done is enable the feature by setting cacheRolesInCookie="true". This is false by default. I've shown the rest of the role cookie-related settings just so you can get a feel for what's available for tweaking. These are the default settings you'll get if you simply omit these attributes, and if you're familiar with the Forms authentication configuration, they should look familiar. Unless you really know what you're doing, you should leave all of these settings at their default values (the easiest way is to simply omit them from web.config), with the exception of cookieRequiresSSL.

If you're running your Web application over SSL (which you really should be doing if you're using Forms authentication), I recommend setting cookieRequiresSSL="true" (more importantly, you should also set requiresSSL="true" in the <forms> configuration element as well). This prevents the cookie from being sent over a nonsecure connection and potentially being stolen by an eavesdropper. This is particularly important for the forms login cookie, because if it's stolen, it can be replayed by an attacker, allowing him to impersonate the user from which the cookie was stolen. This is a very nasty attack, and it's surprisingly easy to pull off. Most Web developers (and hackers) have cookie editors[15] that make it easy to use any cookie they want with your application.

[15] My favorite cookie editor plugin for Firefox is called Add & Edit Cookies, which you can download from http://addneditcookies.mozdev.org/.




Essential ASP. NET 2.0
Essential ASP.NET 2.0
ISBN: 0321237706
EAN: 2147483647
Year: 2006
Pages: 104

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net