Case of the crumbling cookies

3 views
Skip to first unread message

Rene Churchill

unread,
Jul 14, 2009, 10:50:01 AM7/14/09
to Burlingt...@googlegroups.com
Sometimes I can find the most novel ways to shoot myself in the foot.
In this case, I managed to get conflicting cookie values being sent
back to me from the browser.

Normally, when you use the setcookie() call in PHP, the domain is set
to whatever domain the user connected to the website with. No
problems unless you happen to change that domain for some reason.
(i.e. switch from using foo.com to www.foo.com) in which case you've
just lost all of your previous cookies.

To fix this particular nit, you can set cookies using the wildcard
domain .foo.com (the leading dot makes it match any subdomain of
foo.com)

However, if you still have cookies set with the domain: www.foo.com,
you'll now get two cookies coming back from the client browser, with
potentially conflicting values. Which one wins and winds up in
$_COOKIE appears to be undetermined but consistent. (i.e. if the
domain .foo.com wins on a particular page, it will always win on that
page, but on some other page www.foo.com will win)

My current hack/workaround is to unset all of the www.foo.com cookies
in every header. Does anybody know of a way to get access to the raw
headers in PHP so I could check if the www.foo.com cookies are set
first?

Rene

Stanley Brinkerhoff

unread,
Jul 14, 2009, 11:13:48 AM7/14/09
to Burlingt...@googlegroups.com
Rene,

A few thoughts...

First, if you are relying on the data that is in the cookie for something (such as address and location), I would highly suggest you implement a low level encryption algorithm to protect those values from being mucked with.  I also hope you are sanitizing them as they come back to your server (is your latitude really -zebra^2 ?).  If you do this, you should really only end up with a single cookie value -- and your front controller can break the cookie data back out from the serialized, encrypted entry to local variables.

The session_set_cookie_params function might also be helpful (http://us2.php.net/manual/en/function.session-set-cookie-params.php).

But -- to answer your question -- getallheaders (http://php.net/getallheaders) if you are using Apache.

Cheers,

Stan

Bradley Holt

unread,
Jul 14, 2009, 11:18:52 AM7/14/09
to Burlingt...@googlegroups.com
Rene,

What about setting up a permanent redirect to the canonical domain --
is that an option? For example, redirect all www.foo.com to just
foo.com (or the opposite, if you prefer). Not sure if this would fix
your problem, but it might eliminate one of the variables contributing
to the problem.

Thanks,
Bradley

On Tue, Jul 14, 2009 at 10:50 AM, Rene
Churchill<rene.ch...@gmail.com> wrote:
>
--
http://bradley-holt.blogspot.com/

Jase Roberts

unread,
Jul 14, 2009, 12:06:15 PM7/14/09
to Burlingt...@googlegroups.com
Hi Rene, try "Live HTTP Headers" extension for FireFox to see exact
HTTP headers being sent and received:
https://addons.mozilla.org/en-US/firefox/addon/3829

You'll want to close other tabs or set a filter in Live HTTP Headers
to only look at the domain you're interested in. If something like
Gmail is open, you'll get a lot of headers mixed in as it refreshes
every few mins.

Cheers,
Jase

On Tue, Jul 14, 2009 at 10:50 AM, Rene
Churchill<rene.ch...@gmail.com> wrote:
>
--
+------------------------------+
Jase Roberts
802.272.6406 . ja...@jaseroberts.net
http://www.linkedin.com/in/jaseroberts
red wiggler compost worms: http://vermontworms.com/
+------------------------------+

Rene Churchill

unread,
Jul 14, 2009, 1:01:18 PM7/14/09
to Burlingt...@googlegroups.com
I'm using the Web Developer addon to FireFox to look at cookies, it's
nice in that it will show just the cookies for the page you're looking
at. You can also wipe all cookies for that domain or path at a click
of a button.
https://addons.mozilla.org/en-US/firefox/addon/60

Rene

Rene Churchill

unread,
Jul 14, 2009, 1:07:02 PM7/14/09
to Burlingt...@googlegroups.com
This is probably worth doing just from an SEO perspective.

Rene Churchill

unread,
Jul 14, 2009, 1:09:39 PM7/14/09
to Burlingt...@googlegroups.com
Hey Stan,

Thanks for the pointer to getallheaders(), unfortunately that doesn't
show the domain that the cookie was set for. At this point, I don't
believe that information is returned to the server by the browser. Ah
well.

The cookie information was sanitized before use, I don't trust
anything the user can muck with. At this point, I'm pushing all of
the cookie information into the session, so there will only be one
cookie to worry about.

Rene

Stanley Brinkerhoff

unread,
Jul 14, 2009, 1:53:34 PM7/14/09
to Burlingt...@googlegroups.com
Given your love of performance -- would memcache complement a simple session, as sessions are typically serialized to disk?

Stan

Jase Roberts

unread,
Jul 14, 2009, 2:11:22 PM7/14/09
to Burlingt...@googlegroups.com
Hi Rene,

The advantage of the Live HTTP Headers extension is that it will let
you see in real-time what cookies the server is sending to the browser
(and when), and what the browser is sending back to the server. It
takes a bit to get used to if you're not accustomed to reading
headers, but it gives you a much better idea of exactly what is going
on than the cookies tool in Web Developer can.

Live HTTP Headers is also invaluable in diagnosing problems with
redirects and Location: headers.

Cheers,
Jase
Reply all
Reply to author
Forward
0 new messages