Good eye Robert, I agree, the steps involved could be tricky.
Your suggestion is interesting, but maybe dropping the use of <@USERREFERENCEARGUMENT> altogether is even better. Just my thinking..... 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:14 PM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Critical Issue > > > I'm not so sure about this. Since Witango will attempt to attach the > user variable store to a request based on the cookie (then ARGs) > -BEFORE- any code is executed, this would mean that the > request in which > you are assigning the Witango_Reference cookie would itself not have a > valid user variable store. You would, in this case, have to > refresh the > user to regain their cookie based user var store, and a refresh like > this would be somewhat tricky. > > I wonder if a special ARG like > "Force_UserReference=123456789012345678901234" might be > something to put > on the wish list. > > Robert > > -----Original Message----- > From: Ben Johansen [mailto:[EMAIL PROTECTED] > Sent: Friday, September 05, 2003 2:21 AM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Critical Issue > > If this is the case then you could force the new session cookie to use > the > non-ssl UserReference by forcing the _UserReference passed as a search > arg > into the ssl session cookie > by the following > > <@ASSIGN Witango_UserReference VALUE=<@ARG _UserReference> > SCOPE=COOKIE> > Do this as the First code encountered > > this would re-establish the link. > > Though I could see where change the precedence could have a profound > effect > > Ben Johansen - http://www.pcforge.com > -Authorized WiTango Reseller > http://www.pcforge.com/WitangoGoodies.htm > -Authorized Alt-N Reseller > http://www.pcforge.com/AltN.htm > > -----Original Message----- > From: Stefan Gonick [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2003 8:31 PM > To: [EMAIL PROTECTED] > Cc: Robert Shubert > Subject: Re: Witango-Talk: Critical Issue > > > 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 > > ______________________________________________________________ > __________ > 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
