I have an issue with Roles.IsUserInRole function. It take hell amount of time to just check if the logged-in user is in particular role(typ 3-9 sec). I searched to find a solution and arrived on this but I am not sure If I have fully grasped it.

What I got from the above, A new derived class is created. Inside that class, there is a list which retrieves all user at once. The next time you check IsUserInRole, you do not use the actual IsUserInRole method but rather use the one you overrode in your class. Is this the correct description? Am I on track?

My question is, can data be share between two different users in ASP.NET application? If yes, will the shared data exist only if there is at least one user logged in. If all users logs out, that shared data is destroyed? My point is this data will be created only one time whenever a user logs in. For all subsequent users they can use this data and check their roles against the list? I need a detailed answer.

My application has users and different roles. We are using ASP.NET roles.

  • This really belongs on stackoverflow.com, not here.
    – Graviton
    Feb 9, 2012 at 14:57
  • 1
    It would be a fit there too but this question is really about design so I thought it can be explained better here.
    – TheTechGuy
    Feb 9, 2012 at 16:09
  • This is on-topic here.
    – user8
    Feb 9, 2012 at 19:33

3 Answers 3


As @Quagmire said, yes you can share data between your users, and the best choice would be to use the Application scope (see How To Store Data in the Application Scope).

That way, you don't need to cache anything.

However, I have a remark. I don't know enough about the application you are writing, but be careful about storing user roles, and never refreshing that information. If the user roles change in your database (or place where you are storing these information), your application would need to be restarted for these changes to be known... Not very pretty.

If the user roles never change, Application is good enough. However, if they change, there is a better solution, use ASP.NET's caching infrastructure. You can even define sliding and absolute expiration that will effectively remove the user roles information from the cache at some point.

I checked out the article linked by @KenHenderson, and he basically does that except that he sets no sliding/absolute expiration which means the cache never gets refreshed.

What I would do is attempt to improve his nice solution by setting a sliding expiration time of 30 minutes. After thirty minutes without activity, the information is removed from the cache, and the next time the user connects to your application, the user roles are refreshed.

  • very helpful. I am looking
    – TheTechGuy
    Feb 9, 2012 at 16:07

Yes data can be shared between two different users. There are many ways to do this the quickest and dirtiest would be a static field. Other options include a shared DB, file, etc.

As far as your speed issue, my suggestion would be to create a role provider that derives from your current role provider. Then modify the role provider to cache the user's roles somewhere, probably in [Session][2] the first time it tries to check the user's roles. Any subsequent check would hit the cache and not incur the cost of getting the roles. To be honest I would probably actually cause the roles cache to be populated when the user was initially authenticated since the user will have an expectation that logging in will take some period of time that isn't expected when just requesting a page.

Updated response due to comment

How you do your caching is going to depend on your requirements, design, and architecture. So without specifics on your implementation it'll be difficult to answer your question with regard to how you expire the cached roles. Personally my first cut would be to do an individual cache for each user, which is why I referenced Session above. Assuming that the standard first this process goes something like

  1. GET some page
  2. REDIRECT to Login page
  3. POST Login page
  4. REDIRECT to originally requested page

You might be able to asynchronously populate the cache in step 3 which would limit the delay when processing the request from step 4. This would require some coordination work that might delay the rendering of the page in step 4 if the caching has completed yet.

A quick google search for "WindowsTokenRoleProvider slow" revealed some results for others that have had this issue. This article describes at least one cause and offers a reasonable solution.

  • I am thinking on exact same line. But I am concerned/not sure about a few things. Lets say for the first user in the morning, it will get longer about 9 second to build the cache. For all subsequent login, it would be hitting cache? 2. Lets say everyone logs out at the end of the day. This shared cache will die? And in the next day, it will take usually longer for the first user to login and for all subsequent, it should be quick. That is as long as at least one user is logged on, the shared cache will not die?
    – TheTechGuy
    Feb 9, 2012 at 14:03
  • investigating ..
    – TheTechGuy
    Feb 9, 2012 at 14:40
  • @Dave check out what I wrote about expiration time. If the cache has no expiration time, the cache never dies unless the ASP.Net application is destroyed (server/application restart).
    – Jalayn
    Feb 9, 2012 at 14:57

You have to Implement basepage and all page needs to be derived from baseage.

public class BasePage : System.Web.UI.Page


public partial class LoginScreen: BasePage


Or you can use session variable. set

HttpContext.Current.Session["IsUserInRole"] = true;  


bool IsUserInRole = Convert.ToBoolean(HttpContext.Current.Session["IsUserInRole"])
  • 3
    -1 this answer doesn't answer the question of sharing data between users or the problem with the WindowsTokenRoleProvider performance. Feb 9, 2012 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.