Just a heads up about a somewhat related issue. Last time this thread came around we backed up our files, removed the user ref args and went live. it worked great for us, but when our clients came in (school districts) they started reporting wierd problems.
As it turns out, the user ref arg made the URL's more unique and they didnt get cached. When the user ref args were gone, pages were getting cached and that was causing problems. We reverted to our backed up files and Scott said you could get around this by putting a random number on the end of each URL. We havent tried it yet but I'm sure it will work, just wanted to give you a heads up on this for anyone whose going to be converting. ----- Original Message ----- From: "Scott Cadillac" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 13, 2004 1:42 PM Subject: Re: Witango-Talk: Cookies > Hi Stefan, > > > Your examples are clear assuming that the Witango server doesn't care > > that a userref has expired and just reuses it. To me, that is where the > > problem > > lies. If session cookies are disabled, the server should still be able > > to > > determine > > that UserRefA was an old expired one and assign a brand new one. This > > would > > make all of the scenarios secure and usable without having to jump > > through > > programming hoops nor stop using @userreferenceargument. > > To actually accomplish what you're proposing likely involves some form of URL rewriting - > you're just introducing a different set of hoops to jump through. No thanks. > > Through all the hoops away, and just stop using <@USERREFERENCEARGUMENT>. > > > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
