I've recently encountered a problem, and I believe I know the reason, I just
wanted to take a quick poll of the list to make sure I'm on the right track.
We've built a system that involves a user logon and maintenance of some user
variables. Occasionally we're running into a problem where a user in a
completely different geographic location picks up the variables from someone
else logged on. Unfortunately, we have no standard architecture for browser
requirements, so we could have the whole range from Opera to Firefox to IE
running, no to mention a wide range of security settings and firewalls set
up.
Now, I believe that for whatever reason, the session cookie sent to the
browser is getting lost. Does this sound correct? I imagine the only cure
for this is to include a <@userreferenceargument> in every single URL
request we make with WiTango? Still sound correct?
This is slightly different between T2K and W5x.
T2K would accept a user reference argument (URA) first from a search arg and then from a cookie. This meant that you could easily hijack a user session by using the same user reference in a search arg. This was an issue when a url was sent out with an embedded URA in it or was indexed by a search engine with a URA in it. The cookie URA was a lower priority and was set by the URA in the URL. T2K was not able to get URA info from a post arg.
In W5x the the server will look for a URA in the following order cookie first, search arg and then post arg. If a URA is not found in any of these then the server will assume that the request is a new user session.
Unless you have a real nasty ISP downstream, there is not much chance of the cookie going missing as the set-cookie is sent in the http header. The only way it would go missing is if a proxy/cache was rewriting http headers.
You should always use a <@userreferenceargument> in the url of each request to allow users who have cookies turned off to be able to keep a session state on your site. The user reference argument is a 24 byte number based on 2 random numbers and a time stamp so the chances of you getting a duplicate is extremely improbable.
The first place I would look is for a page that could be cached that sets the URA prior to the user reaching the login screen. Also check if the user has cookies turned on. To do this create a taf that sets a cookie and a taf that reads the cookie and have the user hit the tafs. Also check the logs and see what the user references and IP addresses are for the 2 users at the time of the session hijack.
My guess is a link or a bookmark that has a user reference hard coded into it followed by a caching issue at an ISP.
Witango Support
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
