Stefan wrote: > 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.
It is pretty easy to make your taf's do this for you: Check at the top for the existence of a user$identifier variable that you yourself create at the beginning of a properly initiated session. A session trying an old expired userreference won't be able to find its old expired variables. If it does not exist, redirect to your initiation taf or call your initiation tcf (not including a userreferenceargument), where a new one will be assigned, and your code will create that new user$identifier variable. I have followed what seems to be the Cadillac of all Witango development advise, and stripped userreferencearguments out of my code, with no harmful side-effects. Anybody whose browser doesn't even allow session cookies also cannot do on-line banking or much of any useful business in their browsers. Bill On 13 Oct 2004 at 16:18, Stefan Gonick wrote: > 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. > > With Enterprise: What do you say? ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
