Hi Alan, If I understand your question...
Connecting to a Database with Witango would only be related to the UserReference business "if" you were using User Scope Variables for your Datasource connection information. (similar to what I describe here http://xmlx.ca/articles/571.aspx ) Hope this answers your question. 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: "Alan Wolfe" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Tue, 20 Jan 2004 09:59:31 -0800 Subject: Re: Witango-Talk: Cookie Bug > does anyone know if it relies on the user reference when connecting to > a > database? > > ----- Original Message ----- > From: "Scott Cadillac" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, January 20, 2004 8:53 AM > Subject: Re: Witango-Talk: Cookie Bug > > > > Hi Robert, > > > > Please see my comments below... > > > > > I only want it to be a session cookie. The problem is that the > header > > > in its default state, was not righting the cookie when it should > have, > > > namely when there was no userref search arg and there was no > userref > > > cookie in the browser. > > > > Keep in mind that the order of checking (for an existing > USERREFERENCE > > key) is "session-cookie" first, then @searcharg, then @postarg. > > > > This behavior was changed in 062 I think(?). This is a good thing :-) > > > > > > > In the witango manual v5, it states that the > <@userreferencecookies> > > > tag is the same as this: > > > > > > Set-Cookie: Witango_UserReference=<@USERREFERENCE>;path=/<@CRLF> > > > > > > Except that the <@userreferencecookies> tag doesn't write a cookie > on > > > every request, but checks for the search arg, and a current cookie > > > first. > > > > See my comment above. > > > > The Witango_UserReference session-cookie is "only" written if > > USERREFERENCE is "not" found in a request from either the > session-cookie, > > searcharg or postarg. > > > > > > > It is this action of "checking" that I believe is broken. When I > > > > > > replaced the <@userreferencecookies> tag with the text above, the > > > cookie is always set properly, and session state is never lossed. > > > > > > I hope that makes sense, I am running on little sleep. > > > > > > Also, I want to create a "check" method of my own, so that I don't > > > overwrite a cookie with the same value when I don't need to. So I > first > > > > > > must read in the Witango_UserReference cookie, right? So I try to > read > > > it in by <@var cookie$Witango_UserReference>, but it returns > nothing, > > > even though I can see the cookie in my browser prefs. > > > > I understand that the "Witango_UserReference" value is not accessible > as > > a "cookie" variable - only via <@USERREFERENCE>. I think this is by > > design, to help preserve the integrity of the session-key. > > > > I would recommend that you absolutely "confirm" your suspicions of > this > > bug by using an HTTP Sniffer tool of some sort. > > > > Because of the order of checking is session-cookie first, it is > possible > > that you have a rouge cookie floating around, or a malformed HTTP > header > > that is messing things up for you. > > > > By using a HTTP Sniffer tool, you can actually see the Request and > > Response HTTP Headers, and all the cookies (session and others) being > > passed from Server-to-browser-to-server. > > > > You can save yourself hours of work by seeing the HTTP Headers in > action, > > as opposed to building code to trap for "predictable" values. Plus > you'll > > gain a better understanding of how HTTP works - a must for all Web > > Developers. > > > > Here are some choices: > > ~ http://www.httpsniffer.com (30 day Trial) > > ~ http://www.pocketsoap.com/yatt/ (Free) > > ~ http://www.google.com/search?q=http+sniffer+trace (if not on > Windows) > > > > Note: HTTP Sniffer tools do not work 100% of the time when starting > them > > up, sometimes you have to re-start them more than once before you see > > activity. This is just the nature of tracing tools. > > > > Hope this helps. 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) > > --------------------- > > > > > > > > > > > > > > On Jan 20, 2004, at 7:01 AM, Ben Johansen wrote: > > > > > > > Ok, I am trying to get a better understanding of your state > issue. > > > > Because in you sample code > > > > > > > >> HTTP/1.1 <@HTTPSTATUSCODE> > <@HTTPREASONPHRASE><@CRLF>Content-Type: > > > >> text/html<@CRLF><@SETCOOKIES>Set-Cookie: > > > >> Witango_UserReference=<@USERREFERENCE>;path=/<@CRLF><@CRLF> > > > > > > > > you didn't set the end date time of the cookie, so it would > expire > > > when > > > > the browser session was changed or ended. > > > > > > > > Hence <@var cookie$Witango_UserReference> would yield nothing. > > > > > > > > Maybe, I'm not fully understanding when you are loosing state :-b > > > > > > > > What if you set the following > > > > > > > > <@ASSIGN NAME=myTest SCOPE=cookie VALUE="<@userreference>" > > > > EXPIRES="<@TOGMT TS=<@SECSTOTS SECS='<@CALC EXPR="<@TSTOSECS > > > > TS=<@CURRENTTIMESTAMP>>+108000">'> FORMAT="datetime:http">"> > > > > > > > > 108000 = 30 minutes (default variable timeout) > > > > > > > > Let me know how far I am off the mark :-) > > > > > > > > Ben Johansen - http://www.pcforge.com > > > > Authorized Witango & MDaemon Reseller > > > > Available for Witango Developement > > > > > > > > > > > > -----Original Message----- > > > > From: Robert Garcia [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, January 20, 2004 8:56 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: Witango-Talk: Cookie Bug > > > > > > > > One more thing. > > > > > > > > In order to create my own "Cookie Check" method, I was doing some > > > > tests. If I set a simple cookie, like <@assign cookie$myTest > "This is > > > a > > > > > > > > test.">, I can verify the cookie is set through my browser prefs, > and > > > > then read it back with <@var cookie$myTest>. > > > > > > > > However, If I verify that the Witango_UserReference cookie is set > in > > > my > > > > > > > > browser, if I try to read it out with <@var > > > > cookie$Witango_UserReference>, I get nothing. I don't want to use > > > > <@userreference> because that will not necessarily verify if the > > > cookie > > > > > > > > is written. > > > > > > > > Any ideas? > > > > > > > > Robert. > > > > > > > > > > > > > > > > On Jan 20, 2004, at 5:15 AM, Robert Garcia wrote: > > > > > > > >> I have been working through cookie issues and loss of state > issues > > > for > > > > > > > >> months, and I have been able to reproduce the problem. I am > using > > > 065 > > > > > > > >> on windows by the way. > > > >> > > > >> It seems that the <@userreferencecookie> tag is supposed to > check > > > the > > > > > > > >> instance of the userref either as a search arg, or in a cookie, > and > > > >> only write a cookie if none present. > > > >> > > > >> However, sometimes, even with no userref in the search arg or > > > cookie, > > > > > > > >> sometimes the cookie is not written ( this usually happens when > a > > > user > > > > > > > >> first hits the site). What makes it worse is that I use the > > > >> <@userreferenceargument> in every link on the site, and since it > > > gets > > > > > > > >> created on the first hit, and the cookie didn't get written, the > > > >> cookie definitely doesn't get written in subsequent hits, > because > > > the > > > > > > > >> search arg userref is always there. > > > >> > > > >> As a quick test I replaced the default header: > > > >> > > > >> HTTP/1.1 <@HTTPSTATUSCODE> > <@HTTPREASONPHRASE><@CRLF>Content-Type: > > > >> text/html<@CRLF><@SETCOOKIES><@userreferencecookie><@CRLF> > > > >> > > > >> With: > > > >> > > > >> HTTP/1.1 <@HTTPSTATUSCODE> > <@HTTPREASONPHRASE><@CRLF>Content-Type: > > > >> text/html<@CRLF><@SETCOOKIES>Set-Cookie: > > > >> Witango_UserReference=<@USERREFERENCE>;path=/<@CRLF><@CRLF> > > > >> > > > >> This manually sets the cookie on every hit, and seems to solve > all > > > my > > > > > > > >> problems. Until I build a class to check first then write the > > > cookie, > > > > > > > >> I will keep this, it doesn't seem to hurt performance to much. > > > >> > > > >> This definitely seems to be a bug, and a pretty significant one. > I > > > am > > > > > > > >> super busy, but I will try to send this up to witango this > weekend > > > >> unless someone already has. > > > >> > > > >> It would seem to me that it would be better to check if the > cookie > > > >> exists, and write it if it doesn't regardless if the search arg > > > >> userref is there. I am thinking through how this may be affected > if > > > >> someone bookmarks a page with a search arg userref, and then > uses > > > it. > > > > > > > >> So I am going to work on a method, any thoughts would be great. > > > >> > > > >> -- > > > >> > > > >> Robert Garcia > > > >> President - BigHead Technology > > > >> VP Application Development - eventpix.com > > > >> 5910 Clark Rd Suite G > > > >> Paradise, Ca 95969 > > > >> ph: 530.645.4040 x222 fax: 530.645.4040 > > > >> [EMAIL PROTECTED] - [EMAIL PROTECTED] > > > >> http://bighead.net/ - http://eventpix.com/ - > http://theradmac.com/ > > > >> > > > >> > > > > > > > > _______________________________________________________________________ > > > >> _ > > > >> TO UNSUBSCRIBE: Go to > http://www.witango.com/developer/maillist.taf > > > >> > > > >> > > > > > > > > -- > > > > > > > > Robert Garcia > > > > President - BigHead Technology > > > > VP Application Development - eventpix.com > > > > 5910 Clark Rd Suite G > > > > Paradise, Ca 95969 > > > > ph: 530.645.4040 x222 fax: 530.645.4040 > > > > [EMAIL PROTECTED] - [EMAIL PROTECTED] > > > > http://bighead.net/ - http://eventpix.com/ - > http://theradmac.com/ > > > > > > > > > > > > _______________________________________________________________________ > > > > _ > > > > TO UNSUBSCRIBE: Go to > http://www.witango.com/developer/maillist.taf > > > > > > > > > > > > > > > > _______________________________________________________________________ > > > > _ > > > > TO UNSUBSCRIBE: Go to > http://www.witango.com/developer/maillist.taf > > > > > > > > > > > > > > -- > > > > > > Robert Garcia > > > President - BigHead Technology > > > VP Application Development - eventpix.com > > > 5910 Clark Rd Suite G > > > Paradise, Ca 95969 > > > ph: 530.645.4040 x222 fax: 530.645.4040 > > > [EMAIL PROTECTED] - [EMAIL PROTECTED] > > > http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/ > > > > > > > _______________________________________________________________________ > > > _ > > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > > > _______________________________________________________________________ > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
