Hi Robert, > I know how to easily check if they differ, that is not the issue. The > issue is that my fix write the cookie even if it already exists with > the correct value. So I would like to read in the UserRef cookie to > check it before writing, but it seems there is no way to actually > verify if the cookie exists in the browser, and check its value.
Have you tried an HTTP Sniffer yet? > What fixes are in the 5.01.066 wiis.dll? I am using 065. > > also, since I have done my workaround, I have had several people try to > > break session state all day. It is rock solid now, and all I did was > replace <@userreferencecookies> with the set cookie clause from the > manual. > > I cannot think of any configuration on my end that would make this > problem unique to me accept that this is an extremely trafficed site > where the problems are noticed. I was using the default header before, > with the header.tml file blank. I even checked that the default header > was being created properly by checking the value of <@var > system$httpHeader>. See above. You could probably be saving yourself a lot of time. Hope this helps. Cheers... > Robert > > > On Jan 20, 2004, at 11:03 AM, Robert Shubert wrote: > > > Robert, > > > > Didn't mean to bug you about the version, the fix for the session > > cookie > > bug in 062 was primarily done in the client, so if the versions were > > out > > of sync your results would be sporadic. The latest version of the > > wiis.dll is 5.0.1.66 > > > > Of course, I have to say that there is something somewhere as I have > a > > similar setup, with two Witango servers, and do not see the results > you > > are seeing. My headers are the default and my user sessions are no > > longer lost, they certainly were under previous versions. > > > > Actually, what you are looking for is to see if <@USERREFERENCE> and > > <@ARG _userreference> differ. The reason is because your previous > page > > would have been processed under USR#1, all links on the page would > > therefore pass USR#1 in the ARG, however, if the cookie is not read > or > > misread, or if there is some other problem in setting up your user > > scope > > for the subsequent request then <@USERREFERENCE> should be USR#2 and > > not > > agree with the ARG. > > > > I would install an @IF at the top of a suspect app, reset the headers > > > to > > default, and email yourself (or log) the ARG and <@USERREFERNCE> > > anytime > > they are different. Of course if the ARG is not present, that's not > an > > issue. > > > > Lastly, you WILL have user session loss IF you switch between domains > > multiple times, ie, going from www.website.com to secure.website.com > > and > > back again. > > > > You could also have user session loss if you hard coded a USR, but > I'm > > doubtful that is the issue, and this is now less likely with session > > cookie preference. > > > > Robert > > > > -----Original Message----- > > From: Robert Garcia [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 20, 2004 1:34 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Witango-Talk: Cookie Bug > > > > Well, > > > > That makes sense, but using the <@userreference> tag is not the same > as > > > > checking for the cookie, because the <@userreference> tag will return > a > > > > value if the cookie is not present. > > > > I am absolutely certain I am using 065 of the client, and the > servers. > > I have the client running on a single webserver, pointing to two app > > servers in a load group. > > > > <@userreference> and <@arg _userreference> are the same and is not > the > > issue. > > > > I have 4 people trying to lose session, and it seems to be rocksolid > > now, since I have replaced <@userreferencecookies> with the actual > Set > > Cookie clause. > > > > Also, I have a test server, running the client and server on the same > > machine, which has the same reproducable problem, and the same > > workaround fixed it also. Also confirmed 065. > > > > When I upgrade from previous versions, I uninstall, and do a clean > > install, and just move in my ini files manually. So it is clean. > > > > Robert. > > > > On Jan 20, 2004, at 9:01 AM, Robert Shubert wrote: > > > >> Robert, > >> > >> You can not retrieve the Witango_UserReference cookie value with the > >> @VAR tag. This was explained to me by Phil at one point which boiled > >> down to the fact that the value was the name or key of the > >> userreference > >> and was processed before other values were set. <@USERREFERENCE> > >> produces the result. > >> > >> Please double check that you are using .065 both server and > plugin/cgi > >> as corrections to cookies were made in versions between .062 and > .065 > >> > >> Also, double check that <@USERREFERENCE> and <@ARG _userreference> > are > >> always the same, you might have an issue there. Because the > processing > >> order was switched to Cookie > SEARCHARG > POSTARG, it is now better > > to > >> not pass _userreference unless you are sure that session cookies are > >> not > >> supported or that you are switching domains, where it is required. > >> > >> Robert > >> > >> -----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 > > > > > > -- > > 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
