We have an ASP.NET MVC application for which we have developed our own custom RoleProvider class. Without caching it will access the datastore for every request – bad. The only caching option we can find is (in web.config) via cookies stored on the clients’ machines. My two questions are:
- Is this secure (even with encryption enabled)?
- Will the cookie information be transmitted with every web request – thus, potentially, slowing the application more than accessing the datastore every time?
Does anyone have an alternative route? I understand that caching this information in the Session is also bad?
If you have developed your own custom RoleProvider class, you can do your own data caching, e.g. using the ASP.NET cache. This is more flexible than using Session as a cache, since it will work even on pages that don’t have session state enabled.
I don’t agree with Wyatt Barnett’s comment that:
It’s OK for a cache (whether Session, the ASP.NET Cache or something else) to be volatile – you just need to repopulate it when required.
To answer your questions:
It’s as secure as the encryption used to encrypt the cookie. If you’re relying on FormsAuthentication, it need be no less secure than the Forms Authentication ticket.
The cookie will be transmitted with every request. So there is a potential performance hit if users can have a very large number of roles, and the potential to exceed the maximum cookie size supported by the browser.