Thank you Phil, I concur completely! I've spent a lot of time in other environments, and this is precisely the same rules these other platforms employ for Session management.
Web programming is a stateless world, and session-cookies are the norm for providing any measure of reliable and secure Session (User) variables. Without getting into custom deployed browsers. Changing the order of the precedence like Phil did is also key here, because this is also brings Witango more in-line with how other platforms operate and complies with industry accepted practices. The Session-cookie is the primary key-holder (as it should be), and alternate search arguments are the "backup strategy" only to be used if absolutely needed, and even ignored if a different session-cookie is present. Although the Internet can probably never be 100% secure, you can get it pretty-good. And session-cookies are nearly impossible for "general users" to hijack accidentally or on purpose. Yes, technically it is possible for a User to turn off their session-cookies, but most modern Browsers do have separate settings for regular cookies and session-cookies, with session-cookies sometimes being the harder to turn off. Browser developers recognize the importance of session-cookies for web-applications. Modern browsers are like this is because from a functional, operational and security point-of-view, regular cookies and session-cookies are different. It's one thing to make your web-applications as browser and user friendly as possible, but to make it too user friendly in terms of security is a mistake. Don't try and compensate for when the User unwittingly turns off something important and "safe". I'm not "telling" you how to program, but in my out-spoken opinion, it's better to error on the side of caution and deny someone access because their session-cookies are turned off, then to give them access too freely because you're trying to make it easier for an anonymous user. This is where exploits are born. In stepping down from my soapbox, I would just like to sum up with: <@USERREFERENCEARGUMENT> is fine for non-sensitive, non-critical use, but you can avoid many serious headaches later by not using it. It is certainly your best "backup strategy" if session-cookies are not an option - but should still remain just that, a backup strategy (your second choice). This was just one programmers opinion and I am not a representative of the fine folks at Witango.com Thank you for listening to me :-) 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: Phil Wade [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 20, 2003 9:20 PM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: Loss of Session State Issues. > > > > 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 > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
