Just an update, It appears, after some testing by their IT department, that the bypassing of caching on their firewall and changing the httpHeader has corrected the problem. I appreciate all the input form you all.
WebDude -----Original Message----- From: Scott Cadillac [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 6:02 PM To: [email protected] Subject: Re: Witango-Talk: variables getting muxed No problem Ben, I had done my homework on this one a long time ago. This number of line-returns is important, because although html output will accept more than 2 line-returns between the HTTP header and the content, binary and some xml (ajax) output will not. Hope you're doing well buddy. Take care. Scott, On Wed, September 26, 2007 6:25 pm, Ben Johansen <[EMAIL PROTECTED]> said: > Sorry, > > didn't mean any implication, just that the dbl crlf are needed that is > good to know on the userrefcookie > > Ben > > On Sep 26, 2007, at 1:07 PM, Scott Cadillac wrote: > > Hi John, > > Remove the last @CRLF. > > If you read the Witango documentation, the @USERREFERENCECOOKIE > metatag already includes a @CRLF. > > My original code was correct. > > Scott, > > > On Wed, September 26, 2007 4:26 pm, Ben Johansen <[EMAIL PROTECTED]> > said: > >> yeah, >> in html pages sent out there has to be a blank line starting with >> CRLF between Header and Content since you are making the header you >> need to provide the blank line. >> that is what the 2nd CRLF does >> >> Ben >> >> On Sep 26, 2007, at 12:22 PM, WebDude wrote: >> >> Well, now I am confused. I have this in a text file right now, all on >> one line. Are you saying I should add another <@CRLF> at the end and >> then make sure I clear all the whitespace? So it would look like >> this? (no line breaks)... >> >> <@purgeresults><@ASSIGN local$httpHeader VALUE="Content-Type: >> text/html<@CRLF>Cache-Control: no-cache, max-age=0, must-revalidate, >> proxy-revalidate<@CRLF>Pragma: >> no-cache<@CRLF><@USERREFERENCECOOKIE><@CRLF><@CRLF>"> >> >> >> >> John Muldoon >> Corporate Incentives >> 3416 Nicollet Ave S >> Minneapolis, MN 55408-4552 >> 612.822.2222 >> [EMAIL PROTECTED] >> >> http://cipromo.com >> >> >> -----Original Message----- >> From: Ben Johansen [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 26, 2007 1:50 PM >> To: [email protected] >> Subject: Re: Witango-Talk: variables getting muxed >> >> yes >> >> you also need to make sure that there are 2 CRLF's at the end, >> >> so you either add another <@CRLF> to this and clear white space after >> (put cursor at end and hit delete a bunch ;-) or leave as is and >> delete all white space at end and then hit CRLF once. >> >> Ben >> >> On Sep 26, 2007, at 11:40 AM, WebDude wrote: >> >> How do I do that? Like this?... >> <@purgeresults><@ASSIGN local$httpHeader VALUE="Content-Type: >> text/html<@CRLF>Cache-Control: no-cache, max-age=0, must-revalidate, >> proxy-revalidate<@CRLF>Pragma: >> no-cache<@CRLF><@USERREFERENCECOOKIE><@CRLF>"> >> >> >> >> >> -----Original Message----- >> From: Ben Johansen [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 26, 2007 1:33 PM >> To: [email protected] >> Subject: Re: Witango-Talk: variables getting muxed >> >> you might want to throw a <@purgeresults> just in front of that and >> place it in its own results action and make sure it is the first >> action that the taf see to ensure no other header gets sent >> >> Ben >> >> On Sep 26, 2007, at 11:17 AM, WebDude wrote: >> >> Thanks guys. And yes, I found hundreds of posts on cookies in some of >> the old Tango and Witango threads. I actually learned quite a bit. >> >> As for upgrading, its not in the cards this week... However, you all >> make a good point and an upgrade is going to have to come soon ;-) I >> need to get things here upgraded across the board. >> >> Scott, >> >> Can I just paste this at the top of every page? I have about 50 sites >> on this server and would prefer to limit the change in the http >> header to this project only... >> >> <@ASSIGN local$httpHeader VALUE="Content-Type: >> text/html<@CRLF>Cache-Control: no-cache, max-age=0, must-revalidate, >> proxy-revalidate<@CRLF>Pragma: >> no-cache<@CRLF><@USERREFERENCECOOKIE><@CRLF>"> >> >> >> >> >> John Muldoon >> Corporate Incentives >> 3416 Nicollet Ave S >> Minneapolis, MN 55408-4552 >> 612.822.2222 >> [EMAIL PROTECTED] >> >> http://cipromo.com >> >> >> -----Original Message----- >> From: Scott Cadillac [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 26, 2007 12:05 PM >> To: [email protected] >> Subject: RE: Witango-Talk: variables getting muxed >> >> My experience has been basically identical to Jesse's. >> >> Plus, from very early days with Tango 4, once I figured out how to >> control my HTTP headers I never used the <@USERREFERENCEARGUMENT> in >> any of my applications - and the ones that are still running today >> are without issue. >> >> When NOT using <@USERREFERENCEARGUMENT>'s, session-cookies do become >> a requirement, but that's a standard policy with any website or web >> app that has any sort of user management. >> >> By default every browser has session-cookies enabled and so this >> won't be an issue with your users. >> >> And session-cookies are NOT the same as regular cookies as far as >> modern browser settings are concerned (some may want to debate this >> further, but I won't). >> >> It's perferred to place this assignment in some common TCF or include >> for all your TAF files, but the following is how to notify any >> proxies and browser not to cache content. >> >> <@ASSIGN local$httpHeader VALUE="Content-Type: >> text/html<@CRLF>Cache-Control: no-cache, max-age=0, must-revalidate, >> proxy-revalidate<@CRLF>Pragma: >> no-cache<@CRLF><@USERREFERENCECOOKIE><@CRLF>"> >> >> The above was copied directly from my old tango 2000 codebase. >> >> Hope this helps. >> >> Scott, >> >> >> On Wed, September 26, 2007 1:37 pm, Jesse Parker >> <[EMAIL PROTECTED]> >> said: >> >>> 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: [email protected] >>> 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: [email protected] >>> 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: [email protected] >>>> 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: [email protected] >>>>> 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 >>> >>> >> _____________________________________________________________________ >> _ >> __ >> 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 > > ______________________________________________________________________ > __ 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
