Ian
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Daniel
Sent: Friday, June 07, 2002 4:45 AM
To: Multiple recipients of list witango-talk
Subject: RE: Witango-Talk: FW: Proxy Server Problems
Dan .. my comments are in blue ... and I'm spelling this out so carefully, because I know that this is a confusing subject for many people, and it's important to get it right.
Ian
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Dan Stein
Sent: Friday, June 07, 2002 4:27 AM
To: Multiple
recipients of list witango-talk
Subject: Re: Witango-Talk: FW: Proxy Server
Problems
So this is how it applies in my case.
The 1st user
hits the page with just a static call to a
TAF.
The direct URL which goes to login.taf. It is
direct.
They then log in and get the user variables set.
The second
person logs in
not so fast. The second person hits the same URL **but never gets the file from the server.** Because the URL was a static URL that happens to end with "login.taf," the proxy server serves it up, c/w HTML that contains hyperlinks with user reference number in them and your no-caching arg, etc. They then log in, but their user reference number was already attributed to them, because they posted from a form with a user reference number that was taken from the cached version of the logon form.
and you think they get the userreferance
number
from the 1st person. Correct, but they
didn't get it from Witango; they got it from the proxy
server.
They then log in but now see the main menu with
all
there own user variables. Correct, and
we now have two concurrent people, each on a separate machine, using the same
user reference number.
Then the 1st person goes back to
login.taf which is where the main menu
button takes you and since there
reference number has been hijacked by the
proxy server for the second person
they now get the second person user
variables. Correct.
This happens even though I have
the4 random number generator on each post
and href because it is actually the
userreferance number that was hijacked.
Incorrect.
This happens specifically because you *didn't* have the random number on each
and *every* post and href. You were missing it on the very first
hit.
That makes sense.
Looks to me like the quotes
or something are out of place on this
JavaScript. I'll try to get it as a
snippet from you back channel.
Ok
...
Dan
on 6/7/02 1:04 AM, Ian Daniel at
[EMAIL PROTECTED] wrote:
> To Dan and the others relating to the caching
issues .. I offer the
> attached post from the last time that I
wrestled this issue to the ground.
>
> And wrestle it to the ground
we did.
>
> Dan .. I believe that, if you are suffering at the mercy
of a caching proxy
> server, then the attached will solve your
issue. It speaks directly to what
> we spoke by phone about this
afternoon. Interestingly, your name is
> attached to this older
thread, too.
>
> I can attest to the fact that our caching issues
evaporated with the
> introduction of a dynamically-generated URL, per the
JavaScript code below.
>
> And we do know for sure that your first
hit to your taf has no other
> non-caching measures implemented,
meaning:
>
> -- you hit it from a static URL.
>
>
Therefore, the symptoms are predictable, meaning,
>
> -- a static
URL is used to hit a TAF, and the proxy sever caches the
> resulting code,
including the header, which includes the user reference
> cookie and any
page with hyperlinks with a user reference argument appended.
>
> --
a second person hits the same page, and the cached copy of the code is
>
returned, thus giving the same user reference argument out to another
>
person.
>
> Note: this is only a problem if the first user still has
user-scoped
> variables ... or to be specific in your case, is still
logged in. If they
> have logged out, and you have purged the
user-scoped variables, there is no
> (real) harm and no discernable
problem in giving a second person the first
> person's user reference
argument (still undesirable behavior of the code, in
> any case).
Thus, your problem only materializes when, as you said, you have
> higher
load.
>
> If this doesn't solve your problem, I'll eat my
shorts.
>
> ... but you might have to wait until the next Witango
conference to see
> that !! ...
>
> (this better work
!)
>
> Ian
>
> -----Original Message-----
> From:
Ian Daniel [mailto:[EMAIL PROTECTED]]
> Sent:
Sunday, March 11, 2001 3:23 PM
> To: [EMAIL PROTECTED]
>
Subject: RE: Proxy Problems
>
>
> Ah, well ... you see, we've
elevated this discussion some.
>
> The problem of proxies and other
caches ... is largely overcome, when you
> can dynamically generate a URL
that is different every time. Once they log
> onto a Tango (or ASP,
for that matter) application, it's quite easy to
> remember to send them a
unique identifying argument, that means nothing.
> Here at NCOL, we call
that a "no-cache" argument, and it looks like this in
> our snippets
folder, appending onto the end of whatever else we have in the
>
URL. We use a hash of the currenttime, to be sufficiently
distinct:
>
> &_nc=<@CIPHER action=hash
str=<@CURRENTTIME>>
>
> The problem remains, when someone
first hits a TAF, which generates a user
> reference number. They
would normally hit that TAF from a static page,
> hence the first time the
TAF is hit, it could be cached, including the user
> reference number on
all the links it contains.
>
> So, to avoid bringing up the cached
TAF, we need a way to uniquely hit that
> TAF in the first place (or more
accurately, the second place -- for the
> second user to try and hit the
TAF), even though we may do so from another
> cached HTML
page.
>
> Enter JavaScript. The script generates the unique
URL ***in the browser***
> thus defeating any cached TAF page out
there.
>
> I should think it was the was the final chink in our
anti-cacheing armour,
> and should (we'll see tomorrow) solve all of our
outstanding problems.
>
> PS -- for the uninitiated, there is
a separate and very good discussion to
> be had around preventing things
from being cached at all. The thread I
> describe above ... is where
you've done all you can to prevent cacheing, and
> things still
cache. Then what? Then our methods, described
above.
>
> .. or so I hope ....
>
> I will report in
with the results ... but I do believe this will have it
>
licked.
>
> Ian
>
>
>
> -----Original
Message-----
> From: Lee Sobo [mailto:[EMAIL PROTECTED]]
> Sent:
Sunday, March 11, 2001 3:03 PM
> To: [EMAIL PROTECTED]
>
Subject: RE: Proxy Problems
>
>
> To Ian, etc.
>
>
I'm not sure how the random generator, javascript code will fix the
problem.
> I understand that it will create a random url for the logon
page, but what
> about after that?
> ----- Original Message
-----
> From: "Ian Daniel" <[EMAIL PROTECTED]>
> To:
<[EMAIL PROTECTED]>
> Sent: Saturday, March 10, 2001 10:53
PM
> Subject: RE: Proxy Problems
>
>
>> To Dan and
Robert:
>>
>> The two of you had equally good suggestions
using JavaScript, one for the
>> random number generator, the other to
set and retrieve a unique cookie, to
>> force a unique call back to
through the proxy when trying to go from the
>> static page to the
dynamic page. The latter, dealing with cookies, could
>
be
>> defeated by the user ... so I'm less
inclined.
>>
>> I am opting for the random number generator,
like so:
>>
>> <SCRIPT
LANGUAGE="JavaScript">
>> document.write("<A HREF='http://www.domain.com/qry/logon.taf?");
>>
num=Math.floor(99999999999999999*Math.random());
>>
document.write(num);
>> document.write("'</A>Logon");
>>
</SCRIPT>
>>
>> I won't get another chance to test this
with the users 'till Monday
> morning,
>> but I'm feelin' pretty
darned smug about it fixing the problem.
>>
>> By the way, the
number above is about the largest random number a person
>> could
generate. If you add another nine on the end, at least one
browser
>> just returns a zero for the next significant
digit.
>>
>> With serious thanks for your help. I think
we should be away !!
>>
>> Ian
>>
>>
-----Original Message-----
>> From: Dan Stein [mailto:[EMAIL PROTECTED]]
>> Sent:
Saturday, March 10, 2001 6:13 PM
>> To:
[EMAIL PROTECTED]
>> Subject: RE: Proxy
Problems
>>
>>
>> I see the problem. What about using
a random number generator based on
>> JavaScript with the static page
to force the cleared cache from there.
>>
>> If it is caching
software not the proxy server then I am only taking AWAG
>> with the
above and the only other thing I could think of would be to go to
>
a
>> Taf first that dumps the cache and then goes to the
login.
>>
>> Is Tango Cache on or off?
>>
>>
on 3/10/01 7:33 PM, Ian Daniel at [EMAIL PROTECTED]
wrote:
>>
>>>
>>> We have a static home page,
which has a hyperlink to a TAF. Of course,
>> there
>>> is
no URN or other unique identifier yet involved. Clicking that
takes
>> you
>>> to a Logon screen, generated by Tango,
returning a URN. Therein lies
> the
>>> issue, as you'll
see. Here's the sequence:
>>
>> --
>> Dan
Stein
>> Digital Software Solutions
>> 799 Evergreen
Circle
>> Telford PA 18969
>> 610-256-3843
>>
215-703-0783
>> Fax 419-821-3048
>> FMP,Tango, EDI
>>
[EMAIL PROTECTED]
>>
