We store page specific information in the session hash, however we
allocate each 'section' of the site its own sub section of the hash, a
cocnept we sometimes extend to pages that do a lot of session work( using
session->section->page but we do not do that very often, its to much to
monitor ). This
way we avoid conflicts. The FAQ engine uses session{ FAQ } and the search
system uses session{ GlobalSearch } ( in this case to allow the user to
build out their queries progressively ) etc etc etc.
It works well. We maintain pretty tight documentation on our session
hashes which works great as well. When you have multiple developers
futzing with the session it can get ugly. Fast..
John-
On Mon, 12 Jun 2000, Dylan Weed wrote:
>
> I've run across a problem in the way I'm managing sessions, and I'm hoping
> that someone else has encountered the same thing and come up with a smart
> way to deal with it.
>
> I use Apache::Session and I associate each user with their respective
> session hash by giving them a cookie. The problem shows up because, in a
> few places, I use the session hash to store page-specific state
> information (the current page the user is on, for example).
>
> When a user opens a second copy of the site in another browser window,
> they still publish the same cookie. Both the windows are then associated
> with the same session. This means that the two windows can trash each
> other's page-specific state and cause all sorts of undefined behavior.
>
> It seems to me like there are several possible solutions:
>
> 1. Stop the user from ever having the site open in more than one
> window.
>
> 2. Somehow allocate the new window it's own session.
>
> 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.
>
> 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
>
>
