|
It's just a try...
Maybe it help, maybe not...
In our case if have help, but...
regards
Daniel
----- Original Message -----
Sent: Friday, June 07, 2002 2:36 PM
Subject: Re: Witango-Talk: FW: Proxy
Server Problems
As far as I know the Mata Tags are
ineffective since the proxy server never reads the HTML.
on 6/7/02 7:56
AM, [EMAIL PROTECTED] at [EMAIL PROTECTED]
wrote:
Insert as
first a result page with this Meta-Tag in your
Taf:
<META HTTP-EQUIV="Expires" CONTENT="Mon, 06 Jan 1990
00:00:01 GMT">
<META
HTTP-EQUIV="Pragma" CONTENT="no-cache">
This can help.
regards
Daniel Richardy
----- Original Message -----
From: Ian Daniel <mailto:[EMAIL PROTECTED]>
To: Multiple recipients of list witango-talk
<mailto:[EMAIL PROTECTED]>
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] <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] <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]
<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
<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] <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
<http://www.pervasive.com> >
>>
To remove yourself from this list click here:
>>
<mailto:[EMAIL PROTECTED]?subject=unsubscribe <mailto:[EMAIL PROTECTED]?subject=unsubscribe>
>
>> To obtain a list of commands for
this list click here:
>>
<mailto:[EMAIL PROTECTED]?subject=help
<mailto:[EMAIL PROTECTED]?subject=help> >
>>
>> All Subscriptions can be
maintained through http://devtalk.pervasive.com
<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
<http://www.pervasive.com> >
>>
To remove yourself from this list click here:
>
<mailto:[EMAIL PROTECTED]?subject=unsubscribe <mailto:[EMAIL PROTECTED]?subject=unsubscribe>
>
>> To obtain a list of commands for
this list click here:
>
<mailto:[EMAIL PROTECTED]?subject=help
<mailto:[EMAIL PROTECTED]?subject=help> >
>>
>> All Subscriptions can be
maintained through http://devtalk.pervasive.com
<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
<http://www.pervasive.com> >
> To
remove yourself from this list click here:
>
<mailto:[EMAIL PROTECTED]?subject=unsubscribe <mailto:[EMAIL PROTECTED]?subject=unsubscribe>
>
> To obtain a list of commands for this
list click here:
>
<mailto:[EMAIL PROTECTED]?subject=help
<mailto:[EMAIL PROTECTED]?subject=help> >
>
> All Subscriptions can be maintained
through http://devtalk.pervasive.com
<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
<http://www.pervasive.com> >
> To
remove yourself from this list click here:
>
<mailto:[EMAIL PROTECTED]?subject=unsubscribe <mailto:[EMAIL PROTECTED]?subject=unsubscribe>
>
> To obtain a list of commands for this
list click here:
>
<mailto:[EMAIL PROTECTED]?subject=help
<mailto:[EMAIL PROTECTED]?subject=help> >
>
> All Subscriptions can be maintained
through http://devtalk.pervasive.com
<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
--
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
|
