Hi John, Yes, but just make sure there are no line-breaks inside the value attribute (other than the @CRLF's).
All the best. Scott, On Wed, September 26, 2007 3:17 pm, WebDude <[EMAIL PROTECTED]> said: > 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
