Can I share data between two users in an ASP.NET Application?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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;  

get

bool IsUserInRole = Convert.ToBoolean(HttpContext.Current.Session["IsUserInRole"])