Best Practices - User Data & Sessions?

Discussion in 'ASP .Net' started by at_the_gonq@hotmail.com, Sep 13, 2007.

  1. Guest

    Hello,

    I am hoping to get some guidance on the following scenerio:

    I have a password protected site where users have various
    permissions. Are sessions the best way of storing the user's id? And
    if so, on load of a page should I be hitting the database for their
    permissions (based on the session stored user id), or should
    everything I need be stored in session variables to save the trip to
    the database? I have also wondered about serializing the user object
    and sending it from page to page, but I have no idea as to what the
    'official' or 'best' practice is for maintaining this kind of data
    from page to page.

    Any help would be greatly appreciated.
     
    , Sep 13, 2007
    #1
    1. Advertising

  2. <> wrote in message
    news:...

    > I am hoping to get some guidance on the following scenerio:
    >
    > I have a password protected site where users have various
    > permissions. Are sessions the best way of storing the user's id? And
    > if so, on load of a page should I be hitting the database for their
    > permissions (based on the session stored user id), or should
    > everything I need be stored in session variables to save the trip to
    > the database? I have also wondered about serializing the user object
    > and sending it from page to page, but I have no idea as to what the
    > 'official' or 'best' practice is for maintaining this kind of data
    > from page to page.
    >
    > Any help would be greatly appreciated.


    I don't think there is any sort of 'best practice' guidelines for this, so
    here's what I usually do...

    Application object
    Use for high-level lookup data which will change only very infrequently,
    e.g. country codes, currency codes, public holidays etc. However, this is
    really only sensible if the data will be used very frequently by a
    significant number of pages within the web app. E.g. if you have a web app
    with 200 pages and only one or two of those need to refer to public
    holidays, there's little point in caching the data in the Application
    object.

    Session object
    Use for lookup data which is highly unlikely to change throughout the
    duration of a session and which is used by many pages. As you mention,
    metadata about the currently logged-on user is usually a good candidate for
    storage in the Session object. However, I *never* pass Session data between
    pages - there's no point at all, as Session is available to all pages
    anyway...

    Try not to use the SessionID for any sort of reference, as it's not 100%
    guaranteed to be unique across all scenarios. There should be no need to use
    the SessionID for anything anyway, as it's not meaningful data. E.g my
    current SessionID is "X" but yesterday it was "Y" - so what... :)

    Also, bear in mind that when you use inproc sessions, every piece of data
    you store in the Session object eats away at the total amount of memory...
    Obviously, modern webservers tend to have bags of memory anyway, but it's
    still something to consider... I've seen installations where the webserver
    had 512Mb RAM, and each user's Session was over 1Mb big - a few hundred
    concurrent users and the thing will grind to a halt very quickly...

    Finally, if you use SQL Server to persist your Session objects, the above is
    slightly irrelevant as you'll be hitting the database no matter what you
    do... This again needs a bit of planning because e.g. Session_End doesn't
    fire if you're not using inproc sessions...


    --
    Mark Rae
    ASP.NET MVP
    http://www.markrae.net
     
    Mark Rae [MVP], Sep 13, 2007
    #2
    1. Advertising

  3. Guest

    Thank You! This is exactly what I was looking for :)

    On Sep 13, 4:51 pm, "Mark Rae [MVP]" <> wrote:
    > <> wrote in message
    >
    > news:...
    >
    > > I am hoping to get some guidance on the following scenerio:

    >
    > > I have a password protected site where users have various
    > > permissions. Are sessions the best way of storing the user's id? And
    > > if so, on load of a page should I be hitting the database for their
    > > permissions (based on the session stored user id), or should
    > > everything I need be stored in session variables to save the trip to
    > > the database? I have also wondered about serializing the user object
    > > and sending it from page to page, but I have no idea as to what the
    > > 'official' or 'best' practice is for maintaining this kind of data
    > > from page to page.

    >
    > > Any help would be greatly appreciated.

    >
    > I don't think there is any sort of 'best practice' guidelines for this, so
    > here's what I usually do...
    >
    > Application object
    > Use for high-level lookup data which will change only very infrequently,
    > e.g. country codes, currency codes, public holidays etc. However, this is
    > really only sensible if the data will be used very frequently by a
    > significant number of pages within the web app. E.g. if you have a web app
    > with 200 pages and only one or two of those need to refer to public
    > holidays, there's little point in caching the data in the Application
    > object.
    >
    > Session object
    > Use for lookup data which is highly unlikely to change throughout the
    > duration of a session and which is used by many pages. As you mention,
    > metadata about the currently logged-on user is usually a good candidate for
    > storage in the Session object. However, I *never* pass Session data between
    > pages - there's no point at all, as Session is available to all pages
    > anyway...
    >
    > Try not to use the SessionID for any sort of reference, as it's not 100%
    > guaranteed to be unique across all scenarios. There should be no need to use
    > the SessionID for anything anyway, as it's not meaningful data. E.g my
    > current SessionID is "X" but yesterday it was "Y" - so what... :)
    >
    > Also, bear in mind that when you use inproc sessions, every piece of data
    > you store in the Session object eats away at the total amount of memory...
    > Obviously, modern webservers tend to have bags of memory anyway, but it's
    > still something to consider... I've seen installations where the webserver
    > had 512Mb RAM, and each user's Session was over 1Mb big - a few hundred
    > concurrent users and the thing will grind to a halt very quickly...
    >
    > Finally, if you use SQL Server to persist your Session objects, the above is
    > slightly irrelevant as you'll be hitting the database no matter what you
    > do... This again needs a bit of planning because e.g. Session_End doesn't
    > fire if you're not using inproc sessions...
    >
    > --
    > Mark Rae
    > ASP.NET MVPhttp://www.markrae.net
     
    , Sep 14, 2007
    #3
  4. mark4asp Guest

    On Thu, 13 Sep 2007 13:30:57 -0700, wrote:

    >Hello,
    >
    >I am hoping to get some guidance on the following scenerio:
    >
    >I have a password protected site where users have various
    >permissions. Are sessions the best way of storing the user's id?


    Are you using forms authentification? I rely on the UserData property of
    the FormsAuthentificationTicket; and I rewrite the tickets (to the
    cookie) at the start of each new session; after having confirmed the
    user roles from the database (at the start of the session - in the
    AuthenticateRequest event.)

    >And if so, on load of a page should I be hitting the database for their
    >permissions (based on the session stored user id), or should
    >everything I need be stored in session variables to save the trip to
    >the database?


    You only need to hit the database for user information at the start of a
    session; but there is a SqlRoleProvider, should you want it.

    >I have also wondered about serializing the user object
    >and sending it from page to page, but I have no idea as to what the
    >'official' or 'best' practice is for maintaining this kind of data
    >from page to page.
    >
    >Any help would be greatly appreciated.


    You probably don't need to specifically serialize any user objects. But
    you can have custom user objects if you want and these can then be
    managed as per the default.

    Lookup "Role Manager", IPrincipal, RolePrincipal class, GenericPrincipal
    and AuthenticateRequest.

    <http://www.codeproject.com/aspnet/formsroleauth.asp>

    <http://www.codeproject.com/aspnet/aspnet2security.asp>

    Stefan Schackow has an entire book available called "Professional
    ASP.NET 2.0 Security, Membership, and Role Management"; which is an
    amazing 608 pages! Hard to figure why it needed to be so large; but it
    is pretty comprehensive; but not incredibly practical from a cook-book
    point of view. It's hard to recommend this book; the index is not very
    good and what use is a reference book without a very good index?
     
    mark4asp, Sep 17, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. noname
    Replies:
    0
    Views:
    543
    noname
    Jun 26, 2003
  2. karim
    Replies:
    0
    Views:
    474
    karim
    Jul 13, 2003
  3. Josh Harris
    Replies:
    4
    Views:
    3,716
    Josh Harris
    Apr 17, 2004
  4. John Dalberg
    Replies:
    3
    Views:
    583
    samuelhon
    Nov 16, 2006
  5. Chicken McNuggets

    Best book on C gotchas and best practices?

    Chicken McNuggets, Jul 31, 2013, in forum: C Programming
    Replies:
    9
    Views:
    275
    Fred J. Tydeman
    Aug 5, 2013
Loading...

Share This Page