On Tue, 4 Jan 2005 12:47:48 +1100, Steve Onnis <[EMAIL PROTECTED]> wrote: > We are on our 6th, coming into 7th version of CF, and after all this time, > J2EE sessions are the fix to this problem? > > Comeon........... > > Saying this, to me, says that this has always been a problem and only now > with J2EE have we been able to solve it.
My suggestion to switch to J2EE sessions would establish whether it might be due to old persistent CFID / CFTOKEN cookies and was intended to be a debugging aid only. Old CF sessions are managed by persistent cookies and use a simple number for the CFTOKEN value, CFMX added the option to use UUIDs for CFTOKEN which is a bit more secure but J2EE sessions are managed by in-memory browser-based cookies and a secure unique ID generation. If users have visited the site in the past, they will have persistent cookies on disk. If they have old-style numeric CFTOKEN cookies, they are more likely to clash with another session - in my opinion. > I would be looking at how the sessions are set up firstly, is it stored in a > session var environment or is it pulled from a DB That doesn't make sense to me - sessions are managed by cookies, or by tokens in the URL. Client variables may use a database (as well as a cookie!) but session variables do not use a database. However, if someone is doing custom session management, they may well have a coding error that crosses sessions depending on how they're managing the information. > Not everyone has this problem, so it must be a setup or environment issue. Agreed. -- Sean A Corfield -- http://www.corfield.org/ Team Fusebox -- http://www.fusebox.org/ Breeze Me! -- http://www.corfield.org/breezeme Got Gmail? -- I have 6 invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood --- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
