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
