> 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 >
