Alan ... you are correct regarding the precedence in Witango 5.x, re cookies and URA's.
However, consider the case where a user does not yet have either, and is passed a URL containing a URA in an email. They will inherit the other user's session and their variables, if the session has not yet timed out. This is but one example of a URA causing grief. There are others. If the problem is as narrow as you describe, with only a couple of users involved, the people themselves may be able to assist you in the diagnosis of what exactly happened between them to share variables. Just thoughts .. Ian -----Original Message----- From: Alan Wolfe [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 1:51 AM To: [email protected] Subject: Re: Witango-Talk: Inadvertant session highjacking? I thought that in witango 5 and up, when there was a user ref arg and a user ref cookie that the cookie would take precendence, or am i wrong about that? One of the people reporting this problem is a "good user", ie when they have issues they report all pertinant formation, they know better than to use the back button, edit the URL line, double click etc (even though we have tried to gaurd against as much of that as we can), and they said they were just in the system clicking buttons, moving around and all of a sudden were in as another user. Only 2 people that we know of are having this problem and i believe it's pretty rare and they are both from the same district - the same building even so i'm kind of leaning towards thinking it's a network problem on their end, some kinda cacheing going on, or some kind of faulty peice of hardware between them and us. Does that make anything else stick out in your mind? Or is this just sounding like one of those things it would take alot of physical investigation w/ http packet sniffer and stuff to figure out? Kinda sounding like that to me now unfortunately hehe. Atleast it isnt affecting that many people it seems... On 8/24/05, Roland Dumas <[EMAIL PROTECTED]> wrote: > If you use the userreferenceargument, this is inevitable. > > Consider this scenario: > I hit a page and send a link to someone - I'm copying the URL, arguments and > all. If the person hits the URL before the session expires, we're sharing a > session. I've seen this happen (before we nuked userreferenceargs ) where a > chain is set up and people are joining a common session. > > A variation on this is someone sending a URL out to a list or posting it > someplace. > > It's easy to have shared sessions. Party lines, if you will. > > Appending random numbers won't cure this. It's not a cache issue. > > > > > > > > Roland A. Dumas > 310 W. Bellevue Ave. > San Mateo, CA 94402 > 650-347-1373 > 415-412-9300 (cell) > AIM: radumas > [EMAIL PROTECTED] > > > > On Aug 24, 2005, at 12:26 PM, Alan Wolfe wrote: > > Hey everyone, > > I'm part of a company making web based software for school districts, > we just started getting reports from a district we have had on board > for a couple years saying that they are just navigating through the > system and all of a sudden they will be using another person's > session. > > I'm not sure if the HTTP response is going to the wrong place (dont > even know how probable that is) or if a router somewhere is cacheing > the pages or what. > > we use the userref arg on the URL lines because when we take them off, > there are massive cacheing issues. we could do @random instead like > scott has suggested in the past but so far userrefferenceargument has > worked ok for us. > > Since this is the government (we all know how the govt. works!) , I'm > really thinking its a misconfigured network issue on their end but I'm > really not sure, anyone know how to better protect your code from > issues like this? > > Thanks! > Alan > ________________________________________________________________________ > 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
