Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Best Practices - User Data & Sessions?

Reply
Thread Tools

Best Practices - User Data & Sessions?

 
 
at_the_gonq@hotmail.com
Guest
Posts: n/a
 
      09-13-2007
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.

 
Reply With Quote
 
 
 
 
Mark Rae [MVP]
Guest
Posts: n/a
 
      09-13-2007
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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

 
Reply With Quote
 
 
 
 
at_the_gonq@hotmail.com
Guest
Posts: n/a
 
      09-14-2007

Thank You! This is exactly what I was looking for

On Sep 13, 4:51 pm, "Mark Rae [MVP]" <(E-Mail Removed)> wrote:
> <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed) 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



 
Reply With Quote
 
mark4asp
Guest
Posts: n/a
 
      09-17-2007
On Thu, 13 Sep 2007 13:30:57 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) 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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best Codeplex sample for showing best coding practices? John Dalberg ASP .Net 3 11-16-2006 12:07 PM
User Controls/Design Best Practices =?Utf-8?B?TmF0aGFuVg==?= ASP .Net 1 10-02-2004 06:18 AM
Best design practices for user control interaction Josh Harris ASP .Net 4 04-17-2004 12:01 AM
Best sample app for learning best practices, OO & asp.net? karim ASP .Net 0 07-13-2003 04:26 AM
web form user control best practices? noname ASP .Net 0 06-26-2003 03:09 PM



Advertisments