0

I'm working on a portalsystem to share information and documents etc. Each user can have mulitple profiles. Each profile can have different roles and permissions thereby. Now everything is working fine, but I have a question about the MembershipProvider and MembershipUser.

I'm using a custom MembershipProvider and MembershipUser in combination with OpenAccess ORM.

I rely a lot on the (CustomMembershipUser)Membership.GetUser(). For example I build a usermenu where they can see as which user they are logged in and from which profiles they can choose.

To build this menu and collect the groups, roles and permissions for the current profile there are a lot of calls to the Membership.GetUser() from different locations in the code. I first cached the user and returned this based on the ProviderUserKey, but I was told this is unsafe. So I removed the caching, but it was much faster. Is there an alternative, best practice for this?

burning_LEGION
  • 13,246
  • 8
  • 40
  • 52
Michael
  • 31
  • 8
  • I'm thinking of storing the Membership.GetUser() in the HttpContext.Items["MembershipUser"] this will reduce the calls to one each request. Not sure if this is a safe resolution. – Michael Nov 21 '12 at 10:13

2 Answers2

0

There is no 100% solution for your situation, either you have your results cached, either you calculate it every time. The compromiss is to configure cache policies very careful, if caching cause risk your application.

Afaik, caching cause risks in very rare situation, only if you have to apply changes immediately. Consider using some advanced caching policies like cache dependency.

Johnny_D
  • 4,592
  • 3
  • 33
  • 63
0

Session is an appropriate solution based on your description. It is safe enough. HttpContext.Items["MembershipUser"] only keep the user information within one http request while session retain information until session expire.

Cache, however is per application instead per user

Eric Fan
  • 147
  • 9
  • I'm aware of the lifetime of the Context.Items. The win would be one call to the DB instead of multiple each request. I will concider the Session too. I will make some testcases. Thanks! – Michael Nov 21 '12 at 11:28
  • Ah I remember why I moved from Session to Cache. Session is not yet available during HttpModule execution. So I go back with caching and will follow Johnny_D with cache dependency. I should have read my own documentation again. Thanks anyway! – Michael Nov 21 '12 at 12:06
  • Thanks for the feedback. You mentioned you removed caching because of security. I can't see how using cache dependency can enhance the security. – Eric Fan Nov 21 '12 at 13:15
  • Get confused that you not able to access session. I'm pretty sure that session is available when using custom membership provider. – Eric Fan Nov 21 '12 at 13:19
  • I understand your confussion. – Michael Nov 22 '12 at 09:48
  • I can access the Session from within the Membership provider, but not from within a HttpModule during the AuthorizeRequest handler. The Session is only available after HttpApplication.PostAcquireRequestState, and I need it at HttpApplication.AuthorizeRequest. That was the main reason why I went from a Session to the Cache. The security is something I wasn't sure about. I stored the user id encrypted in a cookie to get back the cached item, but I didn't mention that, but that didn't feel safe. I changed that now. – Michael Nov 22 '12 at 09:56