Ok .. take a break, Scott ... I'll try this on .... Stefan .. you are correct in what you have said, but consider this:
If two independent users then find that spidered, expired session ... and each independently come to the site, using the same UserReferenceArgument from the spidered, expired session, and each begin a shopping cart experience, can you imagine the result? Let's see .. I'll place some items in the basket .. you do too. We both head to the checkout .. I put the shipping address, just in the nick of time overwriting yours which you just posted, but I then go looking for my credit card while you complete the order. We then use your credit card to ship an order to me. Are we having fun yet? o[;-) -----Original Message----- From: Stefan Gonick [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 10:17 AM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: Cookies Hi Scott, Forgive me if I find this explanation less than satisfying. :) If sessions typically expire after 30 minutes of inactivity, then spidered sessions would extremely likely have expired by the time someone has clicked on the link. Am I missing something here? Stefan At 01:10 PM 10/13/2004, you wrote: >Hi Stefan, > >Who knows if it ever expired? > >Personally, I think the bug is using <@USERREFERENCEARGUMENT> period. > >Just remove it - and more than one problem is solved. > > >-----Original Message----- >From: Stefan Gonick <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Date: Wed, 13 Oct 2004 12:58:56 -0400 >Subject: Re: Witango-Talk: Cookies > > > What kind of factor can lead to the resurrection of an expired session? > > > > Stefan > > > > At 01:04 PM 10/13/2004, you wrote: > > >Hi Stefan, > > > > > > > I STILL don't understand why UserReferences from a week ago should > > > > lead to session hijacking. Wouldn't this UserReference have expired > > a > > > > long > > > > time ago? Wouldn't that result in creating a new UserReference? If > > not, > > > > wouldn't this be considered a bug? > > > > > >There can be more than one factor involved with why this can happen, > > and > > >therefore hard to > > >eliminate. > > > > > >Keep in mind this problem plagues more web development platforms than > > just > > >Witango. > > > > > >This is more of a flaw in the Internet "architecture" brought about by > > the > > >addition of > > >user "convenience" - but that convenience is superseded now by > > security > > >concerns. > > > > > >Basically, in my opinion - just don't use <@USERREFERENCEARGUMENT> for > > any > > >reason. > > > > > >Hope this helpful. Cheers.... > > > > > > > Stefan > > > > > > > > ===================================================== > > > > Database WebWorks: Dynamic web sites through database integration > > > > http://www.DatabaseWebWorks.com > > > > > > > > > > _______________________________________________________________________ > > > > _ > > > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > > > > > > >______________________________________________________________________ > > __ > > >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > > ===================================================== > > Database WebWorks: Dynamic web sites through database integration > > http://www.DatabaseWebWorks.com > > > > _______________________________________________________________________ > > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > >________________________________________________________________________ >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ===================================================== Database WebWorks: Dynamic web sites through database integration http://www.DatabaseWebWorks.com ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
