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>.
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,to
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 betteranot 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 ismy
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 incookie
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 thefor
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 issuesuser
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_______________________________________________________________________
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
