I did pull the log and it does appear that when the admin user goes in repeatedly as multiple people in the same IE browser even if she does not log out my current system expires the variables for that userreference and then keeping the same userreference reassigns a new set of variables with the new login.
on 12/4/03 20:29, Dan Stein at [EMAIL PROTECTED] wrote: > Scott, > Again I appreciate this and it makes sense but I'd like to here from the > list and from Phil and company about the advisability of removing all the > userreference arguments from the posts and links in the site. > > 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? > > > 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). > > 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. > > Is that expected behavior? Witango engineers seem to imply it is not 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. > > 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. > > 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
