Re: the spiders:
Yes, many bots spider without cookies, yet another reason to only use session cookies and not embed the Userreference.
For the bot, as long as the href is valid, they can follow the link. Of course if the appfile requires some authentication, the spider might just get redirected to a login prompt. If it's relative smart, it will make an MD5 hash of the login prompt response and conclude that all of the pages requiring authentication are the same. (Aside for Scott: self-serving, retrospective rationalization of using redirects to a login appfile, as shown in my write-up on your site, though I can understand the merits of an object oriented approach also).
As the cookie-free bot traverses the links, witango responds with new session cookies, consuming some memory. If this is a problem, you can exclude those robots, or:
*use apache mod_rewrite to append a constant userreference to requests from user-agents corresponding to the troublesome bots, for example www.mydomain.com/deeplink.taf becomes www.mydomain.com/deeplink.taf?_UserReferenceArgument=badbot
*use apache mod_rewrite to strip "?_UserReferenceArgument=badbot" originating from User-Agents that are not the bot
But now you've slowed up apache to save some memory. Probably better to buy some RAM.
On Wednesday, October 13, 2004, at 11:23 AM, Roland Dumas wrote:
Typo corrected
On 10/13/04 11:20 AM, "Roland Dumas" <[EMAIL PROTECTED]> wrote:
In my experience, your explanation is true if the first visitor has cookies off. If cookies are on, witango 5 seems to initiate a new session and assign a new cookie even if there is a URA. Before one considers that an unlikely event, note that many robots don’t use cookies, so will be re-initiating the sessions. Once the cookie-free visitor has triggered a session with the old number, it’s now live for all the cookies-on visitors to join. That’s my experience. YMMV
On 10/13/04 11:10 AM, "Ian Daniel" <[EMAIL PROTECTED]> wrote:
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] <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] <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 <http://www.DatabaseWebWorks.com>
> > > > >
> > > > >
> > > _______________________________________________________________________
> > > > > _
> > > > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf <http://www.witango.com/developer/maillist.taf>
> > > >
> > > >
> > > >______________________________________________________________________
> > > __
> > > >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf <http://www.witango.com/developer/maillist.taf>
> > >
> > > =====================================================
> > > Database WebWorks: Dynamic web sites through database integration
> > > http://www.DatabaseWebWorks.com <http://www.DatabaseWebWorks.com>
> > >
> > > _______________________________________________________________________
> > > _
> > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf <http://www.witango.com/developer/maillist.taf>
> >
> >
> >______________________________________________________________________ __
> >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf <http://www.witango.com/developer/maillist.taf>
>
>=====================================================
>Database WebWorks: Dynamic web sites through database integration
>http://www.DatabaseWebWorks.com <http://www.DatabaseWebWorks.com>
>
>______________________________________________________________________ __
>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf <http://www.witango.com/developer/maillist.taf>
>
>______________________________________________________________________ __
>TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf <http://www.witango.com/developer/maillist.taf>
===================================================== Database WebWorks: Dynamic web sites through database integration http://www.DatabaseWebWorks.com <http://www.DatabaseWebWorks.com>
_______________________________________________________________________ _
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf <http://www.witango.com/developer/maillist.taf>
_______________________________________________________________________ _
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
----------------------------------------- Roland Dumas Roberts Information Services 310 W. Bellevue Avenue San Mateo CA 94402 650-347-1373 415-412-9300 (cell) [EMAIL PROTECTED] SMS: http://new.servqual.com/html/sms.tml
_______________________________________________________________________ _
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
----------------------------------------- Roland Dumas Roberts Information Services 310 W. Bellevue Avenue San Mateo CA 94402 650-347-1373 415-412-9300 (cell) [EMAIL PROTECTED] SMS: http://new.servqual.com/html/sms.tml
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
