I do get it but my explanation was not clear. You have made it very clear.
Dan
on 6/7/02 7:45 AM, Ian Daniel at [EMAIL PROTECTED] wrote:
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
