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
