<@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
