Hi Roland, > now I'm confused. a new visitor gets the userreferenceargument and a > session cookie and they match, right?
That's right. This is an automatic feature of Session Management in Witango. (Unless you are outputting custom HTTP Headers via local$httpHeader - another topic). The <@USERREFERENCEARGUMENT> functionality is a backup strategy for when the session-cookies are missing (browser disabled). If a developer wanted to switch to using the Session-cookie only method (like I do), you simply drop the <@USERREFERENCEARGUMENT> Metatag from your code. Note: I'm not telling anyone to do this, just presenting your options. > 1. What happens when they don't? Highly unlikely. But, for the case when they don't - I understand the <@USERREFERENCEARGUMENT> argument value that is passed back to the Server takes persistence over the Session-cookie being passed back. > 2. what happens if a browser isn't accepting cookies and > comes in on a > stores URL of an expired userreferenceargument? > > concern is that a visitor from one of these search engines > re-energizes > an expired session variable and then the next person from that list > tailgates in on them and sees the same session variables. I haven't a > clue how this works, so please pardon the dumb questions. That's our question in this thread. Whether or not the browser is accepting cookies is unimportant, because the <@USERREFERENCEARGUMENT> value takes persistence I believe. ---- On a side note (I'm actually wondering out load), if the persistence of <@USERREFERENCEARGUMENT> over the Session-cookie of the same value could be swapped - then potentially this problem could be eliminated. Especially if the Witango Server recognizes that the old UserReference key has expired. Witango then issues a new unique key in the Session-cookie and respects that value over the _UserReference argument value. It's not impossible, but certainly much harder to spoof a Session-cookie value than it is a _UserReference argument value. Thus making things more secure. It's just a thought, because maybe I'm just remembering my facts wrong about the persistence. In which case ignore everything I just said :-) ............ Scott Cadillac, Witango.org - http://witango.org 403-281-6090 - [EMAIL PROTECTED] -- Information for the Witango Developer Community --------------------- XML-Extranet - http://xml-extra.net 403-281-6090 - [EMAIL PROTECTED] -- Well-formed Development (for hire) --------------------- > -----Original Message----- > From: Roland Dumas [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 06, 2003 1:28 PM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: RE: Reusing the UserReference key > > > > On Wednesday, August 6, 2003, at 12:12 PM, Ben Johansen wrote: > > > Scott has brought up a point that I missed about user reference > > > > The point is this... > > > > There is a (Tango/Witango)_UserReference session cookie > setup whether > > or > > not you use the <@USERREFERENCEARGUMENT> in the URL. > > > > > > now I'm confused. a new visitor gets the userreferenceargument and a > session cookie and they match, right? > > 1. What happens when they don't? > 2. what happens if a browser isn't accepting cookies and > comes in on a > stores URL of an expired userreferenceargument? > > concern is that a visitor from one of these search engines > re-energizes > an expired session variable and then the next person from that list > tailgates in on them and sees the same session variables. I haven't a > clue how this works, so please pardon the dumb questions. > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
