Ok, Just clarifying here. I am not using a USER variable in the code I am calling the Search ARG and replacing the value the Witango placed in the cookie. You could start your SSL pages with a generic page that doesn't require user variables then have them click to continue. This would create the required trip back to the server to switch the reference values. the user vars from the original reference should be intact.
Ok, I have attached how I have done what I have called a fast round trip. I have done this for other cases and thought it might work here. It check to see if the variable you want is empty and then does the round trip code. This happens really fast. 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: Robert Shubert [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 2: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
FastRoundTrip.taf
Description: Binary data
