Hi Dan, > 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.
Like I mentioned in my first post on this topic: "The key to the issue is how diligently you manage the session(s) with your code." Apparently your code is thorough enough during logon that it is explicitly assigning values for each of your required variable - good on you. But...what about when she's doing one these re-logons (without logging out first) and she mistakenly mistypes a password or something, does your code explicitly <@PURGE> the variables - even though in theory they were never assigned yet, presumably? Or does she sail on through authentication at this point? Just curious. ---- Still, I recommend it's still safer with the "Logon" form to just show her the "Logout" button if variables already exist, instead of the form. This way you can prevent the re- logons. I hope this has been helpful. Cheers...... > 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 ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
