Hi Roland, > Well, I didn't really want to write over the witango_userreference, I > wanted to kill it and cause witango to assign a new one. > I set it to expire in -1 days but when I called <@userreference> it > was still there. So I went and overwrote it with gibberish, looked at > the cookie to verify, and then called <@userreference> - like the > energizer bunny, it was still ticking. So I looked in the witango.ini > and removed the altuserkey value, which was IP address, > restarted, and > the darned userreference was still persisting. Something is > keeping it > in place more than the cookie, and it's surely stronger than a cookie.
If I understand you correctly, this is still happening during a single TAF execution. My guess is that a TAF makes a reference to the memory store (for your User Variables) only once near the beginning of execution. I would think this is by design, to maximize performance. Because to re-reference the memory storage for User Scope every time you access or assign them would just be too much work considering the storage "should" be the same in 99.99999% of cases. > will be stripping userref arguments out, but the hole is still there, > even if it's a bit more obscure. That eliminates accidental > tailgating > and session sharing. Removing the Witango_UserReference session-cookie and managing a re-direct to another TAF "without" the old _UserReference argument removes any holes. There was a good thread on this about a month ago, and a redirect was a major part of the solution I believe. Cheers..... ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
