locked
Which handler event to use? RRS feed

  • Question

  • User-1821407222 posted

    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

     

    Any suggestions?

     

     

    thanks

    Don

     

     

     

     

     

    Thursday, February 8, 2007 6:45 PM

Answers

  • User-1087479560 posted
    Hi,

    In order the role information to be avaliable for later use, you have to append it to the HttpContext each time the request comes.
    So it hits the database everytime.

    In order to reduce the need for accessing database, you can store the role information in the coming request. Like cookie. But it's a insecure way.

    For you situation, I think httpModule is a better choice for you.

    Please let me know if there is any problem.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, March 14, 2007 4:13 AM
  • User-225114762 posted

    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.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, March 14, 2007 3:42 PM

All replies

  • User-1087479560 posted
    Hi,

    In order the role information to be avaliable for later use, you have to append it to the HttpContext each time the request comes.
    So it hits the database everytime.

    In order to reduce the need for accessing database, you can store the role information in the coming request. Like cookie. But it's a insecure way.

    For you situation, I think httpModule is a better choice for you.

    Please let me know if there is any problem.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, March 14, 2007 4:13 AM
  • User-225114762 posted

    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.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, March 14, 2007 3:42 PM