Thank you Robert, for this very comprehensive explanation.... 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) --------------------- > -----Original Message----- > From: Robert Shubert [mailto:[EMAIL PROTECTED] > Sent: Friday, September 05, 2003 3:54 AM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Critical Issue > > > <@CLEARTHROAT> > > Let me see if I can lay out the "possibility". Mind you that > there is a > specific course of events here, and almost any variation will allow > Witango to 'revert' back to a more proper method of dealing > with a USR. > > The scenario is that you have a website at domain.com (pseudonym of > www.domain.com) and you have an SSL key of https://www.domain.com. SSL > keys require the "www" or hostname, whereas most websites treat the > "www" as optional. > > If a user begins at domain.com, a session cookie will be created for > that user. That cookie will be associated with domain.com. > > If you are passing _UserReference with each call, eventually that user > will move to https://www.domain.com for secure traffic, and the passed > _UserReference will establish another session cookie at > www.domain.com. > This cookie will be created with the passed _UserReference and your > application will work properly. > > Now, if the user timeouts their session, or otherwise travels back to > domain.com (without closing their browser), and a new > UserReference and > cookie are established for this second visit, you'll have two > UserReferences in session cookies, which are different from > each other, > one associated to domain.com and the other to www.domain.com. This > distinction is at the web browser level, not in Witango. > > At this point, a problem will occur if the user travels a > second time to > https://www.domain.com, because even though you are passing a new > _UserReference in ARG, the old session cookie will still be in memory, > and now that Witango server will prefer this cookie, a new USR scope > will be started with the old (expired) USR, and your user > will seemingly > loose their variables. > > There are a few different steps that might work out to > produce the same > result, but the main focus is the persistence of a session > cookie, which > can be longer than the user variable timeout, and the fact that web > browsers treat almost any change in the url as a new domain, with new > cookies. > > Because such a long and specific list of events must occur for the > problem to be noticed, it's unlikely that most people will notice. > However, if your login page reverts the user back to domain.com, then > once the problem starts, it will persist until the user's web > browser is > closed. If you move between domain names, such as www.site.com and > secure.site.com, you're at a higher risk of running into this > situation. > Debugging this is a little tough as it will always work the first time > through. > > The obvious solution is to either configure your web server or program > your login TAF to ensure that the user scope is established at the > specific domain where your SSL key is. Or otherwise limit passing the > user between domains or domain variants. > > Robert Shubert > Tronics > > -----Original Message----- > From: Dan Stein [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2003 11:13 PM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: Critical Issue > > Stefan, > > I spoke with Phil in Australia this evening and while we discussed > cookies > and the like he did not mention this or seem to think it was related. > > But if Bob wants to chime in and thinks it is related I would > be glad to > hear the argument. > > Dan > > > > on 9/4/03 23:30, Stefan Gonick at [EMAIL PROTECTED] wrote: > > > I think that the key here is you said that you are losing > > the session as you go from non-ssl to ssl. Prior to version > > 062, the user reference in the search args was given > > priority over the session cookie. This worked great > > for switching to ssl. In version 062, the session cookie > > takes precedence. Bob Shubert can explain this better, > > but switching to ssl only works if the user hasn't been > > there before in which case there is no session cookie > > and the user ref search arg establishes the session. > > If the user goes back and forth in some way (this is > > where Bob needs to step in) there can be a different > > cookie on the ssl URL and, therefore, different user > > sessions. > > > > Damn, it sounded so clear when Bob explained it, > > but it's coming out muddled now. I hope that he comes > > in and clarifies this, but I think that I'm on the right track. > > > > Stefan > > > > At 07:13 PM 9/4/2003 -0400, you wrote: > >> I have a recent issue with a site > >> > >> Witango server V5.062 windows 200 server. > >> > >> Intermittently the session is lost ( I boot them out if the user > variable we > >> need is not present. > >> > >> Rest assured we pass userreferance arguments everywhere and I mean > >> everywhere. > >> > >> We also pass a random number between 100,000 and 1,000,000,000 > >> > >> We also do everything you can with the headers and IIS to force new > pages. > >> > >> Prior to going to V5.062 it seemed the only time session > was lost was > when > >> we might expect it. Improper use of back buttons and > refreshes after > logout. > >> > >> But in the last two weeks we are seeing loss of session when moving > between > >> the HTTP site and HTTPS. > >> > >> The directory does not change just the SSL > >> > >> It is intermittent. When it happens it seems to last about 2 hours > and > >> effect most but not all people. > >> > >> It resolves by itself. > >> > >> I even created a small simple taf that just tests it by printing my > name as > >> a user variable to the page. > >> > >> When it is happening the test file confirms the loss of > session. When > it is > >> not all works fine. > >> > >> When you are booted out the same user reference number comes up no > matter > >> who it happens to and it is a number that was fist used > about 2 weeks > ago > >> from what I see in the logs. > >> > >> So... I stop the service and deleted the file in the Witango Server > variable > >> cache directory and then restarted the server. > >> > >> I submitted the file with my bug report. > >> > >> Does this sound like what other people were seeing on the list? > >> > >> Does removing the file fix the problem? > >> > >> Does it re occur? > >> > >> Has anyone heard back from customer support? > >> > >> This is my biggest client so this is a serious major problem. > >> -- > >> 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 > >> > >> > >> > ______________________________________________________________ > __________ > >> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > > ======================================================== > > Database WebWorks: Dynamic web sites through database integration > > http://www.DatabaseWebWorks.com > > > > > ______________________________________________________________ > __________ > > 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 > > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > > ______________________________________________________________ > __________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
