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
