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
