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: witango-talk@witango.com
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: witango-talk@witango.com
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: witango-talk@witango.com
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: 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
______________________________________________________________________
__
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
