We ran into a really hard to find bug in the cookie handling of Zend_Http_Client, which has been filed as a bug back in August 2007 against version 1.0.1 (today we are at 1.5.2). More over this is a bug that other similar packages have gotten over in 2004.

He had to use wireshark to finally track down the culprit - a call to urlencode on the contents of the cookie before sending it. He also includes some code to overcome a problem he had with UTF-16 in one of his feeds (a custom function that takes in and returns a string translated correctly).

HTTP is a stateless protocol. This means that each request is handled independently of all the other requests and it means that a server or a script cannot remember if a user has been there before. However, knowing if a user has been there before is often required and therefore something known as cookies and sessions have been implemented in order to cope with that problem.

The tutorial is pretty introductory, so if you're not new to the PHP world, you won't learn much. New developers, though, will learn how to set cookies, use sessions and learn a bit about the security of both.

When you start a session, if the user had no cookie, they get a new session id and they get a cookie. You can configure that cookie to last for n seconds via php.ini or session_cookie_set_params(). But, and this is a HUGE but for me, that cookie will expire in n seconds no matter what.

His method provides a way to extend the life of the cookies currently set for the domain by changing the time to live through a series of ini_get calls wrapped in a setcookie() call.

One of the implications of following the rule is related to the whole www vs no-www question. Basically you should always use www if you're planning to use any other sub-domains and you want them cookie-free. This is because you have no way to set a cookie only to the top-level domain.

His code sets cookies for the ".phpied.com", "phpied.com" and "www.phpied.com" domains. Since the domains without the "www" offer a bit broader range of possible matches, he recommends that if you're ever going to use any kind of subdomain, you'll want to use the more broad cookie to cover it.

Anyone who gets me liquored up knows that I'm not a fan of Wordpress. I think it's great from a user (that is, the person writing the content) standpoint, but it has lagged behind severely in terms of security, and I don't believe its popularity is the sole reason WP has been the subject of dozens of vulnerability reports every year. That being said, the WP 2.5 release appears to offer significant improvements in a couple areas: password hashes and cookie data encryption.

He mentions two things in particular - their addition of salted passwords and secure cookies.

I have seen more than one person make the following logic mistake: I may get data via GET, I may get data via POST - Ah, I should use $_REQUEST as it will catch both.

Brian points out the error - cookies aren't in $_REQUEST so improper handling of those values could lead to cookie data overwriting GET/POST data from $_REQUEST. Several of the comments on the post also warn against improper handling of the values, noting that doing so could lead to holes open for attacks (like session fixation).