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
