I have experienced a lifetime supply of issues like this with several different technologies.
In basically all cases the root cause turns out to be aggresive cacheing by the proxy. Try adding lines like this in the HTTP header: Pragma: no-cache Expires: Fri, 30 Oct 1998 12:00:00 GMT (date not important, but should be the distant past) In my experience the standard sessioning mechanisms (cookie, argument) work fine once the proxy understands not to cache. NOTE that using META HTTP-EQUIV tags are not likely to be respected by the proxy server - it has to go into the header. -----Original Message----- From: WebDude [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 12:12 PM To: witango-talk@witango.com Subject: RE: Witango-Talk: variables getting muxed Okay... A few more details. I am using Witango2000. Not sure if this is a problem. Also, the problem is just with this one client. I removed all the <@USERREFERENCEARGUMENT> tags in all urls. All users are surfing through a firewall and are showing up with the same IP address. The hijacks appear to be random. I have asked the client to have all users remove their bookmarks and we will see if this helps. This will eliminate any <@USERREFERENCE>s that have been accidently bookmarked. What is frustrating is that I cannot reproduce any problems here, internally. I also have a firewall and all surfing is done through a single IP. I have logged in as many various users using different browsers, browser sessions, PCs, Macs, etc. Everything here seems to be working as expected. The only time I get a hijack is when I create a new window from the same PC, log in as a different user and go to the original window and hit refresh. What they are explaining to me is that one user will log in on one machine, another will log in on another and see the variables that were set on the first login...huh?!?!?!?! I don't get it. It has to be something on their end, as far as I can tell. This is the only reason I was going to explore the cookie option. Could it be a proxy thing? A caching thing? I was told they just set up a new firewall last week. Unfortunately, I am not sure if this is the issue or not. I just started development of this project 2 weeks ago. It is still in the testing phase. In the past, the only time I have used cookies was to give members of some of our forums a way to not have to log in every visit. I have never had any problems with this. I am waiting for a call from their IT guy to see how they have their firewall set up, but to tell you the truth, I cannot see anything on a firewall that would do something like this. That's where we are at at this point. -----Original Message----- From: William M Conlon [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 9:54 AM To: witango-talk@witango.com Subject: Re: Witango-Talk: variables getting muxed Witango 5+ handles the setup of the session cookie containing <@USERREFERENCE> for you, and this is preferred over using <@USERREFERENCEARGUMENT> in the URL. See the old discussion threads for an explanation, but one of the reasons is to avoid 'session hijacking'. So if you eliminate <@USERREFERENCEARGUMENT>, your user scope variables will still be associated with the <@USERREFERENCE>. There is no need to pass your user scope variables (login, fname, etc.) as cookies. In fact that just exposes them to snoopers. Bill William M. Conlon, P.E., Ph.D. To the Point 2330 Bryant Street Palo Alto, CA 94301 vox: 650.327.2175 (direct) fax: 650.329.8335 mobile: 650.906.9929 e-mail: mailto:[EMAIL PROTECTED] web: http://www.tothept.com On Sep 26, 2007, at 7:21 AM, WebDude wrote: > Okay... I need a cookie education then, I guess. > > I use cookies on some of my forums strictly to remember just a > username. > > On this site, however, there are a bit more variables to be > remembered. > login > lname > fname > password > logged > department > security > officebranch > etc. > etc. > > So, if you kind folks could give me a clue... > > Do I set all of these as cookies? > I would like the cookies to expire at the end of each session, I see > how to do that in the variable set function... what exactly is the > code for setting cookies? I am all over the help pages and cannot find > this. > > Each page (a hundred or so right now) is set to look for <@VAR > logged> and if it is set to 1, it goes to the next elseif. Can I > set <@VAR logged> in the cookie scope and then simply check it? Or do > I have to define the scope too. In otherwords, if I assign it using > the cookie scope, will the following still work? > > <@IFEQUAL <@VAR logged> "1">do this<@ELSE>do that</@IF> > > > Sorry for the stupid questions... > > > > John Muldoon > Corporate Incentives > 3416 Nicollet Ave S > Minneapolis, MN 55408-4552 > 612.822.2222 > [EMAIL PROTECTED] > <ci.gif> > http://cipromo.com > > > > From: William Conlon [mailto:[EMAIL PROTECTED] > Sent: Monday, September 24, 2007 1:47 PM > To: witango-talk@witango.com > Subject: Re: Witango-Talk: variables getting muxed > > Sounds similar to session hijacking (we had a discussion on this In > January 2006). Use cookies instead of passing the userreference in the > URL. > > --bill > On Sep 24, 2007, at 8:02 AM, WebDude wrote: > >> Mmmmmm... >> That sounds like a good idea. Check to see if Vars are set and if so, >> ask them to logout. >> John Muldoon >> Corporate Incentives >> 3416 Nicollet Ave S >> Minneapolis, MN 55408-4552 >> 612.822.2222 >> [EMAIL PROTECTED] >> <ci.gif> >> http://cipromo.com >> >> From: Robert Garcia [mailto:[EMAIL PROTECTED] >> Sent: Monday, September 24, 2007 9:52 AM >> To: witango-talk@witango.com >> Subject: Re: Witango-Talk: variables getting muxed >> >> First, I would remove all references to <@userreferenceargument> in >> urls completely if you are using witango v5.5. >> >> Second, we had an issue like this, and it stumped us for a long time, >> until we watched what the users were doing. Users think, that if they >> open another browser window, or tab, it is a SEPARATE space. They may >> open a second window or tab, and login as another employee, for >> whatever reason, to check something real quick, or whatever, then >> close that window, and expect the previously opened window to work as >> it did, with the former employee. However, the new login, from the >> new window overwrote the user vars, for this session, which includes >> BOTH WINDOWS OR TABS. >> >> The only way to eliminate this, is to check on login, if any or one >> of the user vars are set, if so, you must tell them they have an open >> session that must logout from first. This type of problem usually >> only happens on employee type internal sites, I don't usually worry >> about it with consumer sites. >> >> -- >> >> Robert Garcia >> President - BigHead Technology >> VP Application Development - eventpix.com >> 13653 West Park Dr >> Magalia, Ca 95954 >> ph: 530.645.4040 x222 fax: 530.645.4040 [EMAIL PROTECTED] - >> [EMAIL PROTECTED] http://bighead.net/ - http://eventpix.com/ >> >> On Sep 24, 2007, at 7:12 AM, WebDude wrote: >> >>> Hi all, >>> I have a strange thing happening with one of my clients. We are >>> still in the process on trying to find the problem. It might be a >>> firewall issue on thier end, but I thought I might ask a couple of >>> questions here. >>> I have a site for a company that has around 150 employees. It is an >>> employee site. Each employee has a login and password. When they >>> login, some variables are set to keep track of the user and for them >>> to edit their personal profile. etc. As of Friday, the users started >>> getting muxed. In other words, users would login as one employee, >>> but it shows them as another. This happened several times and I am >>> trying to get to the bottom of it. All users come in on a range of >>> IPs, 5 of them, I believe. I tested , retested, and tested again, >>> but cannot reproduce the problem on my end. I used several machines >>> ALL on the same IP address and logged in as different users on all >>> of these machines to see if I could break it... and I cannot. >>> I did notice that some of the URLs I have in some menus did not have >>> the <@usereferenceargument> while some did. I changed all links in >>> the project to include the <@usereferenceargument> hoping this would >>> help in carrying the correct variables while surfing. >>> Also, since this is a new project and we are still in the testing >>> phase, some of the changes I am making are not being seen by some of >>> the users on their end. I have had them clear cache, re-log in, even >>> reboot thier machines and still these users do not see the changes. >>> I assume that they may have a caching server on thier end that may >>> be a problem. >>> The site was running perfectly okay on thier end until Friday, and >>> then something changed. So their secondary IT guy told me that they >>> just installed a new firewall last week and I am waiting for a call >>> from thier primary IT guy (because he set this >>> up) to see if the problem could be on their end. >>> Questions... >>> Could the fact that some URLs did not have <@usereferenceargument> >>> and some did be a problem? >>> There are a few meta refreshes that go to a different page that did >>> not carry the <@usereferenceargument>, could this have been a >>> problem? >>> Could the fact that they are all coming to the site on just a few >>> IPs be a problem? >>> Could their firewall be a problem and what do I need to tell them to >>> get it to work correctly? Port 80, of course. Cookie enabled, of >>> course... am I missing something? >>> Sine I already worked on this for a couple of hours this morning, I >>> have yet to have them call me with any more problems. I guess I'll >>> have to wait and see if I already corrected any problems on my end. >>> What's wierd is that I have a couple of forums with well over 5000 >>> users for each and I have never had any problems with any of these >>> when it comes to keeping users separate. I have never built anything >>> like this for users coming in on a limited >>> set of IP addresses. >>> Any insight would be appreciated... >>> Thanks! >>> ____________________________________________________________________ >>> ____ 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 > ______________________________________________________________________ > __ 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
