Re: Session-handling and multiple browser windows
On Mon, 12 Jun 2000, Dylan Weed wrote: > Option three (removing all page-specific state from the session hash) > seems like the right thing to do. It is. I don't know any other way to handle this situation correctly. > I'd like to avoid it if possible, however, because it means passing > more information through URLs and having to secure it. Securing it isn't that tough. If you just want to be sure it wasn't tampered with, an MD5 token can take care of it, like Apache::TicketAccess uses. If you don't want people to read it, you can use one of the Crypt:: modules from CPAN. The O'Reilly "Algorithms in Perl" book has a nice discussion of them. - Perrin
Re: Session-handling and multiple browser windows
> 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 >
Re: Session-handling and multiple browser windows
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
>
>
