Re: Session-handling and multiple browser windows

[sh...@isupportlive.com]

> 1.  Stop the user from ever having the site open in more than one
> window.

Pretty inconvenient, no?  Unless this is something that's supposed to
be really tight security I would opt against this.  (I'm sure it's a
bear to implement too.)

> 2.  Somehow allocate the new window it's own session.

Same as 1

> 3.  Don't store any page-specific state in the session hash; limit the
> information that the session hash contains to state that applies to the
> entire session.

This seems to be the "right" solution.  Here's how I usually deal with
this:

Three classes of data:
1) Long Term
2) Session Term
3) Page Term

1:
Stored in database that is refered to by keys in the hash from the
session data once a person has "logged" in.
2:
Stored in session space, this is only a pointer to data that's used on
almost EVERY page.  Store this in a fast database program, mysql,
where as long term data is stored in Oracle, or some other "true RDBS"
(read slow :-)
3:
This data is ephemeral, therefore it seems awkward to store it in your
database, and awkward to store it in your session (Basically same as
storing in database, but it has to be looked up every go round, so you
need to be carefull to keep this data stack small).  So what I usually
do is "store" it in POSTs, or GETs, Get's being better because they're
more likely to "transfer" to the next page when a user clicks on open
in link in a new browser window or something like that.

But there are no hard and fast rules on this obviously.  The one key
thing is to keep your session really small..., the reason for this is
that you can't do incremental updates of session data, it has to
update the entire hash.  Also it has to be read everytime from the
DB... this is a pretty slow process.  So what I try to emphasize is
keep the session data down to stuff that's only used on every page.
(The 80% rule I suppose)  Of course if your only planning on having a
site that is used by a few hundred/thousand people total, then do
whatever you want :), but if you want it to be scalable, you need to
think long and hard about how you're using your sessions.

Shane.

> 
> Option three (removing all page-specific state from the session hash)
> seems like the right thing to do.  I'd like to avoid it if possible,
> however, because it means passing more information through URLs and having
> to secure it.  Have other people encountered this problem, and are there
> smart ways to do option 1 or option 2?
> 
> (If it matters, I'm using HTML::Mason as my templating engine.)
> 
> 	-- Dylan
>