----- Original Message -----
Sent: Friday, June 07, 2002 1:45 PM
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]
>>
>>
>>
>> The
Tango-Talk List Server is a service of Pervasive Software
>>
<http://www.pervasive.com>
>> To remove yourself from this list click
here:
>> <mailto:[EMAIL PROTECTED]?subject=unsubscribe>
>> To obtain a list of commands for this list click
here:
>> <mailto:[EMAIL PROTECTED]?subject=help>
>>
>> All Subscriptions can be maintained
through http://devtalk.pervasive.com.
>> Just Login first and go to the User Options
page.
>>
>> Sent to:
[EMAIL PROTECTED]
>>
>>
>>
>> The Tango-Talk
List Server is a service of Pervasive Software
> <http://www.pervasive.com>
>> To remove yourself from this list click
here:
> <mailto:[EMAIL PROTECTED]?subject=unsubscribe>
>> To obtain a list of commands for this list click
here:
> <mailto:[EMAIL PROTECTED]?subject=help>
>>
>> All Subscriptions can be maintained
through http://devtalk.pervasive.com.
>
Just Login first and go to the User Options page.
>>
>> Sent
to: [EMAIL PROTECTED]
>>
>>
>
>
> The
Tango-Talk List Server is a service of Pervasive Software
>
<http://www.pervasive.com>
> To
remove yourself from this list click here:
> <mailto:[EMAIL PROTECTED]?subject=unsubscribe>
> To obtain a list of commands for this list click
here:
> <mailto:[EMAIL PROTECTED]?subject=help>
>
> All Subscriptions can be maintained through
http://devtalk.pervasive.com.
>
Just Login first and go to the User Options page.
>
> Sent to:
[EMAIL PROTECTED]
>
>
>
> The Tango-Talk List Server is a
service of Pervasive Software
> <http://www.pervasive.com>
> To
remove yourself from this list click here:
> <mailto:[EMAIL PROTECTED]?subject=unsubscribe>
> To obtain a list of commands for this list click
here:
> <mailto:[EMAIL PROTECTED]?subject=help>
>
> All Subscriptions can be maintained through
http://devtalk.pervasive.com.
>
Just Login first and go to the User Options page.
>
> Sent to:
[EMAIL PROTECTED]
>
>
>
________________________________________________________________________
>
TO UNSUBSCRIBE: send a plain text/US ASCII email to
[EMAIL PROTECTED]
>
with unsubscribe witango-talk in the message body
>
--
Dan
Stein
Digital Software Solutions
799 Evergreen Circle
Telford PA
18969
Land: 215-799-0192
Mobile: 610-256-2843
FMP, WiTango, EDI,SQL
2000
[EMAIL PROTECTED]
www.dss-db.com
________________________________________________________________________
TO
UNSUBSCRIBE: send a plain text/US ASCII email to
[EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
