> Could you verify the server's response in this situation: > > Step 1. visit website A (get USR assigned in cookie) > Step 2. visit website B (get another USR assigned in cookie) > > Note that both sites are on the same W5 server. Both sites also use > <@USERREFERENCEARGUMENT>
Session cookies are set per domain name and are valid for all browser windows opened to that domain while the browser is running. Once the Browser is quit (closing a window will not clear a session cookie) the session cookies are cleared from the browser's cookie store. As session cookies are based on domain names both sites will have their own unique Witango_UserReference session cookie based on the domain of the URL. If a request to the server does not have a Witango_UserReference set as a cookie the server searches the searchargs. If the search args do not contain a _userreference then the post args are searched. A failure to find a user reference in any of these will result in the server generating a new _userreference. Note that the first request to any domain will not have a Witango_UserReference set as a cookie so if a user reference is received in a searcharg the witango server accepts it and then sends back a SetCookie: Witango_UserReference= in the http response header with the _userreference value received in the searcharg. Hence the issue with the bookmarked or url in a search engine with user reference allowing 2 people into the same session. > Step 3. wait an appropriate amount of time, so that your USR on site A > has timed out and cleared, but you are still active on site B. > As both sites will have their own unique Witango_UserReference session cookie based on the domain in the URL, when the user returns to site A after the variables have timed out, without quitting the browser, the original Witango_UserReference session cookie will be sent back and a new session initialised with the original Witango_UserReference cookie from site A. There is no problem in doing this as the Witango_UserReference cookie is unique to that browser at that point in time. > Step 4. Jump from site B to site A with <@USERREFERENCEARGUMENT> to keep > your user variables. > > Now I think that the W5 server will get an invalid USR from the cookie, > but a valid USR in the search args. What will the server do? In my case, > The Witango_UserReference cookie will be found before the searcharg and take precedence. The domain will change as you change and the browser will send the appropriate This will ensure that the sessions are kept separate between the two sites. > I need the server to realize that there is a valid USR in the search > args, and use it, rather that creating a new USR based on the fact that > the USR from the cookie has timed out. > If you want to do this make sure that you set the Witango_UserReference cookie first. <@ASSIGN cookie$Witango_UserReference "EA9516BC657E4CC93F44102D">. It is also worth noting that the user reference cookie can be cleared and the next request to the server will generate a new user reference cookie. Just remember that it takes one request to reset the user reference cookie and another request, which comes with a blank userreference, to generate a new userreference. To see this happening put this code in a result html of a taf and call the taf a few times. You will see the userreference change every 2 requests. <@ASSIGN cookie$Witango_UserReference ""> <@USERREFERENCE> > I am seeing a small change in how my servers handle some functions from > pre 058, since I also understood T2K to prefer USR in POST/SEARCH/COOKIE > order. T2K ignored _UserReference sent as a post args. It would look only in searchargs and then cookies. We have changed the precedence to COOKIE/SEARCHARG/POSTARG. We believe this will provide more reliable session management and make it more tamper proof. It also means that a user cannot move from one site to another on the same server and take settings from the previous site with them if they have cookies turned on. If cookies are turned off it is a lot more difficult to manage if you do not set site specific variables in the user scope. ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
