By state you mean that whereas a regular desktop program would run in order
(you click a button it moves to the next screen, fill in info, click a
button and it goes to the screen after that), in a web app, a user could go
to any of the states at any time they want by just changing the url line.
Is that what you mean?
----- Original Message -----
From: "Scott Cadillac" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 13, 2004 11:38 AM
Subject: RE: Witango-Talk: Cookies
> 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
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
