Http://blog.csdn.net/deepbluekk/archive/2006/08/15/1067509.aspx
I. Introduction
In this article, we will discuss the membership, role, and configuration issues of Asp.net 2.0. The membership system in ASP. NET provides a programmable API for creating and managing user accounts. The role allows developers to define a group of roles and associate users with roles. Typically, a website providing user accounts has content that is only accessible to some users, authenticated users, or users with specific roles.
For example, a web site may have a set of pages that allow a trusted user to edit the content of the web site or manage existing users. It is not a simple attempt to hide the page and it is expected that no one will encounter any trouble when browsing it by accident, or hard-coded authorization, but only allows a single user to use it; A stronger and safer way is to define an administrator role and assign it to a group of trusted users. Finally, these management web pages are further configured to allow only users with Administrator roles to perform access operations. Similarly, the web site may contain a group of pages that only authenticated users can access.
Since some parts of the site may only be accessible to some users, this makes it difficult for us to establish site navigation. Do we need to include pages that can only be accessed by authorized users on site maps? If we do this, all users will see restricted pages in the menu or Tree View of the site. Why cannot I display links to these pages to users who access them? If we delete these restricted pages from the site map, the authorized users who want to view these pages cannot easily navigate to them because they are not part of the site map, it does not appear in the Tree View or menu of the site!
Fortunately, ASP. NET 2.0 website navigation provides a feature called secure trim. When you use the function that supports Security trim to obtain site map information, only the site map nodes that are currently logged on to have access authorization are available. This means that the site's Treeview or menu will only contain those parts that can be accessed by the current login user. To learn how to configure site navigation to support secure trim, please read down!
2. Configure ASP. NET 2.0 members and (optional) Roles
Since the site navigation security trim sets the site map data based on the user accessing the page and the authorization settings defined in the page in the site map, before we can analyze the security trim, you must first configure your web site to use ASP.. NET 2.0. (You can also configure the site to use the role and use the role-based authorization advantages, but this does not require displaying the Security trim concept .) The detailed discussion on how to configure a site to use members and roles is beyond the scope of this article.
You can use it if you don't want to spend time installing member and role features on a new web site. Specifically, the Web site that can be downloaded later in this article contains two roles: Administrator and tester. There are four users:
· Superman is the administrator and tester.
· Admin, whose role is administrator
· Mr. tester, whose role is a tester
· Average user, no role
In addition, I have three folders in this project: Admin, tester, and authusersonly. The first two folders have been configured to only allow access by users with administrator and tester roles. The authusersonly folder is restricted only for authenticated users.
3. Configure site navigation for secure trim
By default, secure trim is not used for site navigation. No matter which user is visiting the site and what authorization rules are defined, when each user views site map data through a Treeview or menu web control, you can see all the parts in the site map. By enabling secure trim, the site navigation system automatically limits the display results based on the currently logged-on user and the authorization on the page referenced by the <sitemapnode> element in the site map.
You can use the following mode to configure site navigation settings through the Web. config file:
<Sitemap defaultprovider = "xmlsitemapprovider" enabled = "true"> <Providers> <Add name = "xmlsitemapprovider" Description = "Default sitemap provider ." Type = "system. Web. xmlsitemapprovider" Sitemapfile = "sitemapfilename" Securitytrimmingenabled = "true"/> </Providers> </Sitemap> |
Recall the discussion in the first part of this series-the site navigation system uses the Provider Model. This model provides developers with some well-defined public APIs, but allows (if needed) Customization of internal implementation details. By default, the site navigation feature uses xmlsitemapprovider to retrieve site map information from the XML formatted site map file web. sitemap. You can use the web. config file to change the provider you are using or modify the default settings for the default provider.
To customize the settings of the default provider, simply add a new provider-it uses the same type as the default provider (system. Web. xmlsitemapprovider) to customize the required settings. The code snippet shown above shows the settings for customizing two xmlsitemapproviders:
· Sitemapfile specifies the file name of the site map file used by the provider. The default value is Web. sitemap. If you like it, you can customize the file name here. However, I encourage you to ensure that the site map file name ends with the. sitemap extension because the default extension is protected by the Asp.net engine, thus preventing Web visitors from viewing site map files.
· Securitytrimmingenabled: Set whether to use security trim. To use secure trim, you can set it to true, as shown above.
That's all! The site navigation system intelligently returns the correct part based on the currently logged-on user and the authorization settings defined for the URL in the <sitemapnode> element. The following screen snapshots display the Treeview when anonymous visitors (not logged on yet), common users, and admin users access the page. This anonymous visitor can only see two links-home and my blog. Normal users can see another link-auth users, but anonymous visitors cannot see it, because the URL of this node (~ /Authusers/default. aspx) is configured to only allow authenticated users to watch. The admin user can also see other links because it is an administrator and is a map node of the admin site (~ /Admin/default. aspx) is configured to allow access only by the Administrator.
Treeview when accessed by anonymous visitors |
Is the Treeview for Admin Access |
4. Use Role attributes to prevent security pruning
There may be some times-you want to explicitly notify Security trim not to trim a site map for a special role or a group of roles. For example, if your site map contains a link to an external resource, the site navigation system cannot determine authorization rules for this remote resource. Therefore, it trim the node for all users. That is, if you start the secure trim feature and use a site map with an external link, such as <sitemapnode url = "http://www.scottonwriting.net/sowBlog/" Title = "my blog"/>, no one will see these in the Treeview or menu control. However, you may want the site navigation system to display this node for users with administrator and tester roles. (Or do not consider any user role .)
Similarly, even if they are not authorized to access the resource, you may want to display a local site map node to these users. For example, a user who has not logged on to the website will not see the admin link in the Treeview. However, we may still want to display it. Clicking it will make the user navigate ~ /Admin/default. aspx page. At this time, the system will see that they are not authenticated. This will direct them to the logon page. After logging on, they will be automatically directed back to the admin page. If they are not administrator roles, they will be sent back to the logon page, otherwise they will be allowed to access the admin part.
In order not to trim special roles for a specific site map node, you can use the role attributes in the corresponding <sitemapnode> element. (Note: This setting will not be applied to the descendent <sitemapnode> element. That is, for those roles that explicitly specify other roles that should see this node, you must explicitly set this attribute on each <sitemapnode> element ). This role attribute can contain a role name, a role name that uses the comma-separated list, or an asterisk (*) to represent all users. The following site map files included in the downloaded files at the end of this article show how to use role attributes to make all users have an external site map node reference. (It can be thought that when the security trim function is enabled, if the role attribute is ignored here, this will not display this site map node to any user.)>
<Sitemap xmlns = "http://schemas.microsoft.com/AspNet/SiteMap-File-1.0"> <Sitemapnode url = "~ /Default. aspx "Title =" home "> <Sitemapnode url = "~ /About. aspx "Title =" about "/> <Sitemapnode url = "~ /Admin/default. aspx "Title =" Admins "/> <Sitemapnode url = "~ /Tester/default. aspx "Title =" tester "/> <Sitemapnode url = "~ /Authusers/default. aspx "Title =" auth users only "/> <! -- For links to outside resources, need to explicitly define what Roles shoshould be shown this section --> <Sitemapnode url = "http://www.scottonwriting.net/sowBlog/" Title = "my blog" Roles = "*"/> </Sitemapnode> </Sitemap> |
This role attribute can also be used to add performance improvements to the security trim functionality. After the secure trim function is enabled, the site navigation provider automatically checks the authorization rules for all nodes defined in the site map. For the nodes you want to display to all users, you can bypass this check by adding roles = "*", as shown in the preceding example. By adding this attribute, you can perform a short-circuit normal authorization check to improve the security trim performance.
V. Conclusion
In addition to site navigation support, ASP. NET 2.0 also makes it easy to build a web site that includes user account support and role-based authorization. What follows is not surprising-the two systems can interoperate and provide a site map-the returned content is based on the authorization settings of the currently logged-on user and the URL defined in the site map. Configuring site navigation to restrict the results of user access and authorization settings is as easy as adding some code to the Web. config file.