UserA comes in through Google with UserRefA, which is old. The
Witango server determines that UserRefA has expired and assigns
UserRefB to UserA. Is this correct? If so, UserA continues using the site
and now has UserRefB propagating across all pages through the
<@userreferenceargument>.
UserD now comes in 5 minutes later with UserRefA. Is it true that the
server, at this point in time, views UserD as the same person as UserA, even
though none of UserA's links have UserRefA in them anymore? UserA
now has UserRefB. The server, therefore, allows UserD to join in
UserA's session and gives UserD the same UserRefB?
Is this how it works? This seems to be what you are saying. I find
that hard to believe if so. Alternatively, I may be wrong on the first
question where I assumed that the server would assign a new userref
when it has determined that the old one had expired.
Please enlighten me.
Thanks,
Stefan
At 02:38 PM 10/13/2004, you wrote:
Thank you again Ian,
In addition - anybody remember that statement "the web is stateless"?
It's all about whether or not the Witango server (or any web platform) can tell the difference
between two different people over the Internet - it can't.
As far as Witango (or any web platform) is concerned, because of the session ID in the Search
Engine link - the two users are the same person, thus the shared session.
Removing session information from a URL argument string (<@USERREFERENCEARGUMENT>) is your
first best step in tackling the problem - then relying on session-cookies to uniquely
identifying you over the Internet (provide "state") is the next best step.
The Internet is not perfect and can never be 100% secure - so you have to strive to provide the
best possible solution and security at all times.
Session-cookies are also not perfect - but they are the best option you have.
To understand web programming, you have to understand "state".
Does anybody not know what I mean by "state" in context of the web?
-----Original Message-----
From: "Ian Daniel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Date: Wed, 13 Oct 2004 11:10:41 -0700
Subject: RE: Witango-Talk: Cookies
> Ahh ..
>
> When your User1 came, supplied a UserReferenceArgument ("URA"), the
> server,
> if Witango 5, checked for a UserReferenceCookie ("URC"). Finding none,
> it
> assumed the value of the expired URA, seeing no reason why it should be
> rejected.
>
> Note: I have not tested the above scenario with the very latest
> versions of
> Witango. I am making a rather bold assumption that the above scenario
> ..
> which was true ... is still true. I haven't seen anything which leads
> me to
> believe otherwise.
>
> User 2 came along with the same URA, and having no URC, the server
> obliged
> and allowed the second browser to share the now current variable store
> created by User1.
>
> Does this help? The "error" may be in thinking that the server would
> not
> "honor" the expired URA by establishing a session with the value of
> that
> argument.
>
> tks,
> Ian
>
>
> -----Original Message-----
> From: Stefan Gonick [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 13, 2004 10:37 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Witango-Talk: Cookies
>
>
> Hi Ian,
>
> Thanks for joining in. Let's re-examine your scenario:
>
> User 1 clicks on the link and the Witango server detects
> that the session was expired and starts a new session assigning
> userreference A.
>
> A moment later User 2 clicks on the link and the Witango server detects
> that the session was expired and starts a new session assigning
> userreference B.
>
> It seems to me that the server would assign two different userrefs
> to those users rather than them sharing one. I doubt that
> it stores some connection between the old expired userref and
> the newly generated one. The rest of your scenario would not
> exist if I'm right.
>
> So, how does this really work?
>
> Stefan
>
> At 01:26 PM 10/13/2004, you wrote:
> >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
>
> =====================================================
> 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
________________________________________________________________________
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
