Good points Stefan, This time around I guess I was expressing an opinion rather than a technical solution. It's seems when I give opinions that's when I get my self into hot water :-)
Technically the topic is a challenging one, but like we discussed in our prior thread, I believe this behavior with the shared User Vars many are used to (prior to 062) is more a bug than a feature. And it was only the re-ordering of the UserReference precedence that made it more obvious - because browser session-cookies cannot span multiple domains, whereas the _UserReference argument can. Ultimately there is no one single answer to the situation. Everyone has different needs. So if a Developer (new or not) needed this functionality, they should investigate scoping in all it's complexity because what you are asking for is not a simple thing. Most other professional Web Development platforms wouldn't allow sharing of User Vars across domains. It's when product Engineers try to make things too easy for us, that eventually we pay a higher price for it - can anyone say "Default Scope User"? This can be a complicated topic, but it's not the result of any Wi/Tango Engineer, but the confines of how Session Management works over the web, limited as it is. So mastering complex topics in any language can only benefit you and your skills as a Witango Developer. --- As far as capturing a basket ID from this other scope...presumably you have a common database? Store the basket as you do, but also store the User ID of who made the purchase, then it can be retrieved from whatever scope they logged into. Sorry, I know my suggestion is simplistic, but sharing information across domains can be achieved through a common database as well as a common Scope like "Custom" - then you're not confined to a single server anymore. Have a great weekend..... 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: Stefan Gonick [mailto:[EMAIL PROTECTED] > Sent: Friday, September 05, 2003 4:20 PM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Critical Issue > > > Hi Scott, > > You had actually mentioned another solution to Bob. > That was to assign needed vars to a custom scope > with the same name is the USR. This scope would > be accessible to both domains, non-ssl and ssl. > > Often only one var is needed to make the connection > anyway. In my case, I just need to know the basket ID, > and I'm all set. I can get everything I need from there. > > On public sites, it's common to start at www.domain.com > or domain.com and go to secure.domain.com when > entering a shopping cart payment page. I suppose that > you could force a redirect to ssl right away, but it's > not usually done on public sites. > > The behavior of the server has changed and is causing > challenges in what used to be easy. It would be nice if > there was a simple solution to handle this kind of case > without having to get tricky. New Witango developers > would be helped by this. Telling a new developer to use > a special custom scope or some other trick adds unnecessary > complexity to learning the product. > > Stefan > > At 04:07 PM 9/5/2003 -0600, you wrote: > >Hi Stefan, > > > > > Dropping the <@userreferenceargument> altogether would > > > mean that going to a secure server would never work when > > > the domains are different instead of usually work. > > > >I don't use <@USERREFERENCEARGUMENT> and I run secure sites > for my customers > >- not a problem. > > > >The User variables assigned to a domain deemed sensitive > enough to warrant > >encryption should not be shared with non-encrypted versions > of the domain > >anyway. > > > >The trick here is pushing your customers over to the SSL > site and keeping > >them there. In basic terms, you can minimize this effort by > putting your > >customers onto a HTTPS page "before" they logon - then > everything is just > >relative addressing from there. > > > >Hope this helps. > > > >--- > >And yes, I'm all for add additional functionality whenever > possible to > >Witango - at the same time. Good ideas all. > > > >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) > >--------------------- > > > > > > > -----Original Message----- > > > From: Stefan Gonick [mailto:[EMAIL PROTECTED] > > > Sent: Friday, September 05, 2003 3:52 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: Witango-Talk: Critical Issue > > > > > > > > > Dropping the <@userreferenceargument> altogether would > > > mean that going to a secure server would never work when > > > the domains are different instead of usually work. > > > > > > I would like to see a solution where you could force the USR > > > to be the same as on the other domain. This is in fact how it > > > used to work pre version 062. Since it no longer works this > > > way, it would be great if there was a new search arg that one > > > could use to force it, like Bob suggested. > > > > > > Stefan > > > > > > At 03:38 PM 9/5/2003 -0600, you wrote: > > > >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 > > > > > > ======================================================== > > > 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 > > ======================================================== > 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
