Hi There,

I'm changing the SqlSiteMapProvider in order to fetch the site map from my existing tables. The problem is that the site map should be personalized for each user depending on database data and not on roles.

How can I user SiteMapProvider on a user per user basis ?

Thanks,

Tiago Andrade e Silva

Tiago,
  While it's technically possible for the SiteMapProvider to not cache it's data and requery every time (to get per user data), it will have extremely poor performance and a very high query rate.

  The best technique for this kind of design is to cache the entire sitemap data (for ALL users) in memory and use logic in each of the query functions (CurrentNode, RootNode, ParentNode, ChildNodes, FindSiteMapNode, etc) that are able to filter the in-memory data per user as it is returned. 

  The alternative is to cache the per-user data as it is retreived so that you don't constantly requery the data but this has the potential to easily exceed the memory requirements of the first suggestion.

--
Danny

Thanks for your post Danny!

After googling a bit more I did notice that the class is sealed and that the best thing is in fact the first approach you state: to cache the entire sitemap data for all users.

The way to do this I think is overriding the IsAccessibleToUser method.

"If you want to use your own authorization logic to check if a user has access to a node, you need to override the IsAccessibleToUser method. This method will be called from the StaticSiteMapProvider’s members that we have not overridden in this example, such as the FindSiteMapNode, GetParentNode and GetChildNodes methods etc."

http://fredrik.nsquared2.com/viewpost.aspx?PostID=272&showfeedback=true

Here is another link about Determining a SiteMapNode's visibility at runtime

Sure, that'll do the trick.... I tend to discourage most users from overriding IsAccessibleToUser because they usually do it without understanding the security implications... However, as long as you're aware of the effects and it does the job, go for it!  Read up more on it here: 

http://blogs.msdn.com/dannychen/archive/2006/03/16/553005.aspx

--
Danny

dannychen:

 The alternative is to cache the per-user data as it is retreived so that you don't constantly requery the data but this has the potential to easily exceed the memory requirements of the first suggestion.

Hi Danny,

We have a situation where we're getting our sitemap data via a webservice that uses the user's login info, so we will need to cache the per-user data.  Fortunately our sitemap data is not very large.  My question is how to do this.  I've implemented a custom SiteMapProvider derived from StaticSiteMapProvider, but (obviously) it'll just cache whatever the first user gets. 

How would I adapt my provider to cache per-user data and return it properly?

Many thanks!

Carl

CarlFisher:

We have a situation where we're getting our sitemap data via a webservice that uses the user's login info, so we will need to cache the per-user data.  Fortunately our sitemap data is not very large.  My question is how to do this.  I've implemented a custom SiteMapProvider derived from StaticSiteMapProvider, but (obviously) it'll just cache whatever the first user gets. 

How would I adapt my provider to cache per-user data and return it properly?

I've read this article http://download.microsoft.com/download/2/a/e/2aeabd28-3171-4b95-9363-22150625a6a5/asp.net%20provider%20model.pdf . For my opinion, You must not derive from StaticSiteMapProvider but from SiteMapProvider class.

Deriving from StaticSiteMapProvider is appropriate for custom providers that read node data once (or infrequently) and then cache the information for the lifetime of the provider. Deriving from SiteMapProvider is appropriate for custom providers that query a database or other underlying data source in every method call.

But there are more methods to be implemented than by StaticSiteMapprovider.

Yes, sorry, I never wrote back here with my resolution.  I ended up changing my provider to be based on SiteMapProvider rather than StaticSiteMapProvider.  Dave Sussman was kind enough to supply me with some sample code of a per-user based SiteMapProvider he wrote some time ago that I was able to use to see what I needed to do.  Since my sitemap data is fairly small, I store it in each user's Session.  I can provide more detail if anyone wants when I am back at work tomorrow.

 Carl

And in case anyone wants it, that code is available at http://www.ipona.com/samples/ANV201%20-%20ASP.NET%202.0%20Navigation.zip. This code doesn't do any custom type of caching, nor does it allow for changes to the database menu to change the menu (ie a notification) - I've never had time to do that.

Dave

I'm using a custom SQL-based Site Map provider.

Danny said once that "a page that should not be accessed and cannot be accessed is secure." I think I can control both security trimming (a visibility of page on menu) and accessibility by using IsAccessibleToUser(). I can either:

1) Attach custom SiteMapResolve event handler method and inside check if SiteMap.CurrentNode.IsAccessibleToUser() == true. If it is false - redirect to an appropriate page (default.aspx, for example).

2) Check and do the same thing in master page's  OnPreInit or OnInit() method.

3) Attach some custom page's event handler using HttpModule or global.asax and perform that SiteMap.CurrentNode.IsAccessibleToUser() check and redirect there.

Could you comment on it please? What would be a good/better approach?

Ideally you should be using the <authorization> section in web.config to secure your pages; this protects against direct access (ie the user typing into the address bar) and via the menu, as long as security trimming is supported on the provider. Since this is already built into the framework it saves you haven't to do anything.

If I was writing this myself, I'd probably opt for option 3; a separate module means you don't have to modify any base classes or a master page.

 I cannot use default security trimming mechanism (<authorization>, roles, etc.) because our application implements much more complicated business rules by using its own "Roles and Rights Management System" (RRM). RRM is a much more flexible tool than Windows roles. It is based on three major database tables tRole, tRight, and tRightOfRole (many-to-many relationships). tRole represents business roles like Executive, ProjectManager, etc. tRight represents very granular rights given to roles by adding records to tRightOfRole. There is also a way to assign rights directly to users, and many other features, like per-project roles, etc.

So, my current plan is to use IsAccessibleToUser() method, which in turn would call an appropriate RRM's method to determine page visibility on SiteMap for a current user. I'm thinking about adding a delegate bool AccessibleToUser(int pageID) and assigning this delegate to an appropriate RRM's method during site map initialization. Then, IsAccessibleToUser() would call this delegate, passing (int) CurrentNode.Key, to determine page visibility. This way I would better decouple SiteMapProvider from RRM.

I also think that to assure proper page accesibility I would use a custom page event handler attached to a page event in HttpModule (what event to use? PerInit?) Since I would need to know current pageID and to avoid using of custom base page class just for knowing it, I would re-use SiteMap.CurrentNode.IsAccessibleToUser() here. 

So, both page accessibility and page visibility on Sitemap would be determined by RRM's method (through IsAccessibleToUser() call).

Your model is fairly common actually, the requirement of roles and permissions; more fine grained that just roles. I've seen this implemented as a custom role provider and I'll probably have to do this later in the year for a project. I expect I'll just implement a role provider, but as well as having just Roles I'll attach a custom Permission object to cater for the fine grained permissions.

Dave,  thank you for sharing your ideas on this matter. I wrote RRM about a year ago as VBScript class used in a classic ASP application and now porting it to .NET (C#). I haven't seen any similar applications when I developed RRM and I was unaware on things like Provider model, etc. But a few days ago I found in Fredrik Normén's Blog something very interesting - a Permission Manager. "Permission" might be a better word to what I call "Right".

One problem which I haven't resolve yet is how to add to business objects / collections a knowledge of what Rights are applicable to them, which RRM filter methods to use, etc. In a current RRM it's a responsibility of developer  to apply a correct RRM method (the only exclusion here is an automatic call of RRM.HasRight("CanSeePage") method on each page load.) I briefly looked at Fredrik's Permission Manager and noticed that he is attaching Permissions to business objects themselves, not only to Roles and Users objects. It sounds like he is dealing with that same problem.
I was thinking about using a common base class for all business classes, and a common collection base class for all collections of business classes and adding some kind of an unique typeID field to base class and base collection class. Then, RRM would use those typeIDs to determine an applicable RRM [filter] method. It's still an initial idea and I'm slightly afraid to re-invent a wheel, while a better wheel  already exists

I'm very interested in studying others approaches and ideas on this matter. I'd be happy to share my thoughts as well. Default Windows model is not good enough to mirror complicated business rules.