Hi Dan, > Scott, > Again I appreciate this and it makes sense
You're welcome :-) > but I'd like to here from > the > list and from Phil and company Yes please, I've been around the block on this topic more than once. Someone else speak for a change. > about the advisability of removing all > the > userreference arguments from the posts and links in the site. Did you miss Ian Daniel's presentation at the Conference on session management? He talked about all this stuff. Although I've been saying it for years, it is especially relevent since the changes made by Phil recently to the Witango 5.x series of releases (can't remember which version exactly). Where he changed the precedence of how Witango interprets which key value to respect first when determining which User variables an individual belongs to - now the session-cookie has priority over <@USERREFERENCEARGUMENT> - because it's safer and causes less problems. Basically, use of <@USERREFERENCEARGUMENT> should be considered a "secondary" solution to session management, because of the risks to security and session hijacking and so on. > > Also if you do this in a site where the people go from HTTP to HTTPS > and > back will the witango session cookie still handle that properly? SSL is about protocols, not the domain that UserReferences are associated with. I also run SSL sites, that purely depend on session-cookies (no <@USERREFERENCEARGUMENT>). Never had a problem in about 5 years I've been doing this. > > Finally one thing I am not clear on. Given session-cookie management. \ > > I have one admin user that insists on working this way. > > She logs into the site as herself. > > Then she opens another instance of IE and logs in as a staff member > using > there password and username and does some work on there account (she > could > do this from the admin side but she refuses. Feels it is "cleaner" when > she > does it this way). > As I described earlier, there shouldn't be an issue here - except with some exceptional circumstances that I also described earlier. > Then she logs out and with that browser window open she logs back in > again. > > I can see from the login and out email tracking that sometimes she is > getting the same user5reference number. Actually, she never lost it to begin with. You're just associating different variable values with it now that she has a new logon. > > Is that expected behavior? Yes. > Witango engineers seem to imply it is not News to me...did I miss a post? > you > seemed to say it was. > > And secondary to that. Now that I expire all the user variables not > just on > logout but when you hit the 1st start tml ( which you are forced to in > almost every conceivable circumstance) does it matter that they get the > same > userreference since all the variables have expired. No, it does not matter. The Witango_UserReference session-cookie key is a reference to a memory store location on the Server where you put variables associated with an individual User. The fact that you purge those variables just means the store is now empty, and ready for filling again. It's the logon process (presumably) that decides what values to actually put with those variables in the store. > > I'll pull a log as soon as I get a chance and look at the times I am > tracking in the email because I can see from the log if all the user > variables are gone and have been regenerated again. > > Meantime I am curious to know if I am getting this now. Only you can decide that ;-) Good luck....... > > Dan > > 12/4/03 17:49, Scott Cadillac at [EMAIL PROTECTED] wrote: > > > Hi again Dan, and others, > > > > I know you've been plagued with some very challenging moments Dan, > with a > > project where the > > Network people have been less than helpful. > > > > And as a result, this has probably lead you to re-examine everything > in your > > code. I've been > > in the same boat :-P > > > > But again, and for everyone, there are some very simple rules to > follow with > > regards to > > Session management. > > > > ---- > > Session Management, in a nutshell, is access to User Scope variable > for an > > individual > > visitor to a site. > > > > This is maintained automatically by Witango, with a unique key value > issued by > > Witango the > > first time a visitor hits a TAF or TML file. > > > > This is an automatic feature of Witango, and does not require special > coding > > on your part. > > > > The reason Witango knows this is your first visit, is because the > > Witango_UserReference > > session-cookie is absent from the request - therefore Witango issues > a unique > > value just for > > you. This new value will be re-sent from the browser to the Server > every time > > the visitor > > makes a new subsequent request. > > > > Because of this "hand-shake" process: > > > > --> (visitor's Browser)"Hello, I have no name". > > > > <-- (Witango Server)"Pleased to meet you, I'll name you > > D28D094187265EC83FCF7958". > > > > --> (visitor's Browser)"Hello again, it's D28D094187265EC83FCF7958, > can you > > store some data > > unique to me?" > > > > <-- (Witango Server)"Sure :-)". > > > > --> (visitor's Browser)"It's D28D094187265EC83FCF7958 again - thanks > bud :-)". > > > > > > Witango is now able to maintain an individual relationship with that > unique > > visitor. > > > > And because "session-cookies" expire as soon as a browser window is > closed, > > old key values > > do "not" come back. > > > > ---- > > (by definition) A phrase I've used a lot, means that a > "session-cookie" is > > different than > > other regular cookies because a session-cookie only has a "name" and > a "value" > > - no expiry > > date, no domain assignment, notta. > > > > As a result, all modern browsers treat this cookie special, and only > allows it > > live in > > memory (not the harddrive) and will only send it back to the website > domain > > that issued in > > the first place. A "safe" cookie that is discarded as soon as the > browser > > instance is closed. > > > > --- > > Like I mentioned before, for typical application coding - you should > not have > > to do anything > > special aside from <@ASSIGN NAME="foo" SCOPE="USER">, <@VAR user$foo> > or > > <@PURGE > > SCOPE="USER">. Witango will do the rest - and it does so very > eloquently. > > > > --- > >> Note: the only exception to the above, is when you are assigning > custom > >> HTTP Headers via <@ASSIGN request$httpHeader VALUE="...">, then some > >> special Metatags are required with this assignment. > > > > > > --- > > Of course, there is the issue of <@USERREFERENCEARGUMENT>. > > > > I've been saying it for years, and I'll say it again - don't use it > :-) > > > > At one point in Witango's past, I belive this may have been the only > > "reliable" method of > > uniquely identifying an individual visitor to a website, but it has > always > > been a poor > > solution. But this was more a limitation of older browsers than > Witango. > > > > Modern browsers do a much better job of reliably handling > "session-cookies", > > and all > > <@USERREFERENCEARGUMENT> does now is cause problem, like > session-hijacking, > > tailgating and > > content issues. > > > > With "security" being the utmost concern, don't use it. And if a > visitor can't > > maintain a > > logon because they have mistakenly turned off session-cookie support > - then so > > be it, and > > don't let them in. > > > > Modern browsers do have separate settings for enabling/disabling > regular > > cookies and session- > > cookies, they just may not call it "session-cookies" because that's a > > Microsoft phrase. > > > > --- > > About dynamic content. > > > > Dynamic content is of course a separate issue, and yes, Ian Daniel's > tried and > > true solution > > of appending dynamically generated (JavaScript and/or Witango) unique > > number/string values > > to a request URL, is the best way to ensure a "fresh" request is sent > all the > > way back to > > the Witango Server (which will send a fresh response) - as opposed to > letting > > browsers and > > proxies grab something old from a cache. > > > > > > --- > > I hope this helps, for anybody still reading this far. Cheers... > > > > Scott Cadillac, > > Witango.org - http://witango.org > > 403-281-6090 - [EMAIL PROTECTED] > > -- > > Information for the Witango Developer Community > > --------------------- > > > > XML-Extranet - http://xmlx.ca > > 403-281-6090 - [EMAIL PROTECTED] > > -- > > Well-formed Development (for hire) > > --------------------- > > > > > _______________________________________________________________________ > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > > -- > Dan Stein > Digital Software Solutions > 799 Evergreen Circle > Telford PA 18969 > Land: 215-799-0192 > Mobile: 610-256-2843 > Fax 413-410-9682 > FMP, WiTango, EDI,SQL 2000 > [EMAIL PROTECTED] > www.dss-db.com > > > "When you are born, you cry and those who love you rejoice. And if > you > live your life as you should, when you die, you rejoice and those who > love you cry." > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
