----- Original Message ---- > From: Dai Le <d...@pinneyinsurance.com> > To: user@struts.apache.org > Sent: Wednesday, September 2, 2009 4:59:02 PM > Subject: Session data > > Hi, > > > > I developed a data collection web application using struts 1.2.9 and I've > run into a problem that I cannot find a solution to. The amount of data > being collected is quite a bit so pass the information along in session > variables. The problem arises when a user has multiple instances of the > website opened, the session data is crossed with each other. Because all
Multipe instances as in multiple tabs/windows of the same web browser by the same user? or Multiple instances of different web browsers (FF, IE, etc) by the same user? > the instances share the same session, it's causing the session data to be > crossed or overwritten. Does anyone have any ideas or thoughts on the > matter? Is there any way to create a new session each time the user open a > new instance of my web application. I've tried using URL rewriting and it Let's say that you have some very paranoid users whom disables JS, applets, and cookies, the session would be tracked by by url. You'll have to come up some mechanisms to validate the session against 'copy and paste' of the url. > generates new jsessionids but the clients will to have cookies disabled on > their browser and it's not common to ask users to disable cookies on their > browser. Hope this makes some sense to someone, I'm having a hard Once you have the mechanisms to validate the session, why not keep the session data in the db or possibly to a secured /path/to/private/session/data outside the webapps folder (presumably you're using TC) if you're concerned about taxing your DB server. To prevent the session data from overwritten/mixed, consider using concurrency update method by comparing original data (from source - ie DB, XML, etc), session data, and with new data. This method is a must for multithreaded apps accessing the db, else you'll hear it from your DBA(s) and/or account manager/executive ;) (Note: the user here may not necessarily be the clients, it could be an employee.) Of course, validating the session in a cookieless environment is very hard to implement. If there is some personal information involved, you may have to enforce cookies with some verification mechanisms (including encryption) to protect the users. Trust me, if you ever have to comply with PCI/DSS, it's no joke... Regards, Tommy > describing the problem. Thanks in advance. > > > > Dai Le > > Developer > > Pinney Insurance Center, Inc. > > 2266 Lava Ridge Ct. > > Roseville, CA 95661 > > (916)773-2800 --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
