Best Practices - User Data & Sessions?

[at_the_gonq]

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.

[Mark Rae [MVP]]

<at*********@hotmail.comwrote in message
news:11**********************@y42g2000hsy.googlegr oups.com...

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

[at_the_gonq]

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

On Sep 13, 4:51 pm, "Mark Rae [MVP]" <[e-mail]:

<[e-mail] in message

news:11**********************@y42g2000hsy.googlegr oups.com...

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

[mark4asp]

On Thu, 13 Sep 2007 13:30:57 -0700, at*********@hotmail.com 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?