Re: Witango-Talk: Cookie Bug

[Robert Garcia]

If that is the case, then I would think that there should be a way to  
verify the presence of the userref cookie. The only way I can think of  
right now is to set a user var to <@userreference>, redirect to a page,  
without using the <@userreferenceargument> and then checking for the  
var.

Robert.

On Jan 21, 2004, at 12:51 AM, Robert Shubert wrote:

If I'm thinking about this correctly, If Witango receives a request  
WITH
an ARG but without a COOKIE, it would/could assume that cookies are not
supported by the browser or perhaps by an intervening firewall. In that
case, constantly resetting the cookie might cause an issue (constantly
creating errors) or simply create unneeded overhead.

I'm trying to think if there is a danger to setting a session cookie
FROM an argument. I believe session cookies have some security on them
to prevent hijacking as Scott said, which this would undo that. Session
cookies are also session-specific, and being about to assign an older
USR to a new session cookie again seems to undermine their purpose.
After all, if we have a new session, shouldn't we take the safe road  
and
re-authenticate the user?

Robert

-----Original Message-----
From: Robert Garcia [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 2:04 AM
To: [EMAIL PROTECTED]
Subject: Re: Witango-Talk: Cookie Bug
I am glad I found it too, and I appreciate the help, it was the fact
that others were not seeing the same issue that made me dig deeper.
I agree, that the cookie is not set in a redirect, even if you include
the <@userreferencecookie> tag. So I removed the
<@userreferenceargument> in the redirects to get around this issue.
Although I do see that the <@userreferencecookie> is working as
advertised, and so therefore this is not a bug, I did add a feature
request that the <@userreferencecookie> will in the future write the
cookie if the cookie does not exist, even if the search arg is present.
I think if the cookie is not present, and there is a search arg user
ref, then the cookie should be written with the valud of the search
arg.
Is there a reason that I am not thinking of where the cookie should not

be written if the cookie is not present? I cannot think of one.

Robert.

On Jan 20, 2004, at 10:33 PM, Robert Shubert wrote:

I don't believe that the redirect will ever set cookie because it
would
be unsure which domain to set it for. Redirects have the possibility,
I'd dare say intention, to transverse domains, so you would only be
setting a cookie at the domain you are leaving, and it wouldn't be
useful. Why does the first hit get redirected? Is it to change
'domain.com' into 'www.domain.com'? Because that does constitute a
domain change.
Glad you found it [and we're not all crazy :) ]

Robert

-----Original Message-----
From: Robert Garcia [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 12:32 AM
To: [EMAIL PROTECTED]
Cc: Doug Platt
Subject: Re: Witango-Talk: Cookie Bug
OK, I found the problem. I found why this is happening more for me and
not for others, it has to do with redirecting.
On these apps there are several places where a first time hit gets
redirected. On the first time hit, there is no search arg userref, but
the cookie cannot be set, because it is a 302 redirect. Then, in my
redirect, I attach the <@userreferenceargument> to the redirect
location value, so on the next page the <@userreferencecookie> tag
sees
the search arg and does not write the cookie. Then every subsequent
page, has a <@userreferenceargument> attached in the url, so the
cookie
is not written, then if there is url without the search arg, or
manually put in, session state is lost, because there is no cookie.
The problem is there were bugs in the past, so I have gotten
absolutely
religous with the <@userreferenceargument> and that is actually
causing
a problem, not helping, now that the cookie bug seems to be fixed with
065.
I hope that makes sense. It seems the best thing to do is to go back
to
the default header, and lose the <@userreferenceargument> at least in
my redirects. It seems like there may be a case for not using the
<@userreferenceargument> as a backup.
I will let you know how it works out. It would seem that the
<@userreferencecookie> should write a cookie if it is not present,
using the searcharg as the value if it is there, because unless I just
don't know how to do it, you cannot use the <@userreferencecookie> tag
in a 302 redirect.
I will have to change this from a bug to a feature request, and I now
trying to figure if removing the <@userreferenceargument> from every
redirect is going to cause me any problems anywhere.
Robert.

On Jan 20, 2004, at 9:09 PM, Robert Garcia wrote:

Yes, that is one of the ways I saw that the <@userreferencecookies>
was not working properly.
I built a sniffer in RealBasic that performed http requests like a
browser, and then looked at the value of the http Headers returned.
Even if there was not search arg userref, there were times when the
cookie was not attempted to be written. And my app, does not write
cookies, so there is no way that the <@userreferencecookies> detected

a cookie. Once I did my work around, the set cookie header was
present

every time, and my browser testing confirmed this. If I opened the
browser preferences and watched my stored cookies, I could see when
it

was created, and when it was not. With the default header, if I went
to a witango page without a search arg, the cookie didn't create all
the time, some times it did. Most of the time it did not. As soon as
I

did the workaround, the cookie was created every time without fail.

Robert.

P.S. I can send you an app that will hit a url and then show you the
headers returned. It is a simple app that I wrote, it does the job.
On Jan 20, 2004, at 8:08 PM, Scott Cadillac wrote:

Have you tried an HTTP Sniffer yet?
--    

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