The security of session handling in PHP can easily be enhanced through the use of a few configuration settings and the addition of an SSL certificate. Whilst this topic has been covered numerous times before it still bears mentioning with a large number of PHP sites and servers having not implemented these features.

He talks about the httponly flag when setting the cookie/in the configuration, the "use only cookies" for sessions and forcing them to be "secure only".

Have you ever wondered that in spite of HTTP being a stateless protocol, when you log in to a website and buy stuff and checkout how the server can identify you uniquely? You might wonder if HTTP is stateless but your state is maintained through your interactions, isn't this a contradiction? Welcome to world of cookies (not the ones which we can eat, btw :)), one the of primary ways to maintain user state and interaction between the web browser and the web server.

She shares a lifecycle of a common cookie and describes the parts of the setcookie method (parameters). There's also a few code examples showing how to read and write to them as well as update their values/expirations.

This file is generated by PHP when it runs CURL (with the appropriate options enabled) and can be used in subsequent CURL calls. This file can be read to see what cookies where created after CURL has finished running. As an example, this is the sort of file that might be created during a typical CURL call.

The file is structured, plain-text content with information on the domain, path, security, name and expiration details of each cookie. His script parses out these details and pushes them into a basic array, prime for searching and sorting (and reuse) in your application.

So, why can't you maintain state with HTTP? The main reason is because HTTP is a stateless protocol, meaning that it has no built-in way of maintaining state between transactions. For example, when a user requests one page followed by another, HTTP does not provide a way for us to tell which user made the second request. In this article we will look at what maintaining state in PHP applications entails.

They introduce cookies and how they can be used to store information about the user's session on their client for a certain amount of time. This makes it much simpler for the cross-page or cross-session details to persist. There's a bit of code showing how to set and get a cookie and how to do the same with a session.

There have been a couple of approaches I've been considering [to replace sessions being stored in the database], one of which is simply storing all the information in a browser cookie. First I want to make clear I don't necessarily condone this. The reason I'm writing this post, is because I'm hoping for some more community feedback. Is this a really bad idea? I would love to know.

He includes some code to make it happen - a class that uses the hash_hmac function and a SHA1 encryption type (along with a salt) to convert the information into a string that can be (relatively) safely stored in a cookie. Be sure to read the comments for more opinions on the method.

As it happens I'm very satisfied with the performance of Zend Http when it comes to the fetching and cookie parts. [...] Note [in my example] the use of $client->setCookieJar();, that is all that is needed to manage the logged in state, awesome. Without it the second post to adv_stats.php would've failed due to unauthorized access.

This fetching method pulls in the remote file, parses out the table (as defined by a pattern match) and grabs the rows/columns using getRows and getColumns and manipulates the content inside.

Here are 10 PHP mistakes that any programmer, regardless of skill level, might make at any given time. Some of the mistakes are very basic, but trip up even the best PHP programmer. Other mistakes are hard to spot (even with strict error reporting). But all of these mistakes have one thing in common: They're easy to avoid.

Here's the list (as Glen Stanberry sees it):

• Single quotes, double quotes
• Semicolon after a While
• NOT Using database caching
• Missing Semicolon After a Break or a Continue
• Not Using E_ALL Reporting
• Not Setting Time Limits On PHP Scripts
• Not Protecting Session ID's
• Not Validating Cookie Data
• Not Escaping Entities
• Using Wrong Comparison Operators

Recently the PHP project has been receiving an increasing number of rather silly reports, these vary from simply not reading the manual, searching the internet or a fundamental lack of understanding how the internet works.

He points out three in particular (from the same person, no less) about things that shown an almost complete lack of understand of what PHP does. One was a request to make PHP use less CPU and another asking to make PHP censorship free and, finally, a request to make PHP more secure...by doing away with support for cookies.

Scott also suggests a few constructive things you can do before submitting a good (useful) bug report:

• Gather together as much relevant information as you can (generalizations are bad)
• Run performance checks against older PHP versions to try to pin down when the bug was added
• And, finally: "don't get aggressive or be an asshole when your bug reports get closed".

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.