Last post Mar 14, 2007 03:42 PM by Svante
Feb 08, 2007 06:45 PM|d1camero|LINK
We are using siteminder security, which injects a user's GUID in the header for every authenticated request.
Our web app needs to pick up the GUID and load roles from the database role, then create the proper .Net identity.
So I wrote a Context_PreRequestHandlerExecute, which works, except it hits the database for the roles each request. I tried to check if the
HttpContext.Current.User.Identity.IsAuthenticated - but it always is
Mar 14, 2007 04:13 AM|Raymond Wen - MSFT|LINK
Mar 14, 2007 03:42 PM|Svante|LINK
There are many options, they all revolve around the idea of keeping the info you get from the database somewhere where it is quicker to access it.
Option 1 is to store the info in the client, as is suggested in the previous post, in a cookie or perhaps a hidden field such as ViewState or perhaps ControlState in this case.. That works, and need not be insecure with proper encryption and validation.
It may be expensive in other ways though, as it will have to be sent back and forth every time. You'll have to take care that you actually have access to the info early enough in the cycle though.
Option 2 is to store the info in the server, typically in session state. That also works, but may if you're load balanced you may want to put session state in a SQL server, and then you're basically back to hitting the database every request. This also requires
you to have access to the info early enough, which is not always the case.
Option 3 is to cache the info in context free manner, i.e. put a caching layer in front of the database access. This is my personal preferred option, since it will optimize for just about any scenario. If you use the Cache-class, you get CacheDependency's
for free, you can even in 2.0 get a dependency to the back end SQL server database. The Cache is also self-managing, so you need not worry too much about using up too much memory.