Cookies

Cookies are small pieces of information that are stored in your web browser. They typically contain data that is used to identify you when you look at a website so that site can be customized for each visitor.

Rather than having to pass data to a script by using a form or as values in the query string, cookies are sent back to your scripts automatically by your web browser. Even if you go off and browse to another website, their values are remembered when you return.

For example, if you have to log in to access a particular website, you may be able to let a cookie remember your username so you do not have to type it each time you go back; in this case, you only have to enter your password. Or on a community site, your browser might record the date you last visited in a cookie, so that any forum messages posted since you last visited can be highlighted as new.

Cookie Ingredients

Each cookie consists of a name and a value, just like regular variables in PHP. The instruction to create a cookie in your web browser is sent as an HTTP header before a web page is transmitted; when your web browser sees this header, it takes the appropriate action.

The HTTP headers that create cookies are the same, regardless of whether they are generated by PHP or any other means of interfacing with your web server. The header used to set a cookie called email might look like this:

 Set-Cookie: email=[e-mail] 

HTTP Headers You will never see an actual HTTP header in your web browser. We will look at how different types of HTTP headers are sent in PHP in Lesson 16, "Communicating with the Web Server."

A cookie also has an expiration date; some cookies last only as long as your web browser is open and are kept in your computer's memory, whereas others have a fixed expiration date in the future and are saved to your hard disk. The HTTP header to set the email cookie that will expire at the end of 2005 would look like this:

 Set-Cookie: email=[e-mail];              expires=Sat, 31-Dec-2005 23:59:59 GMT 

If no expires attribute is sent in the Set-Cookie header, the cookie will be destroyed when the web browser is closed.

The other attributes that can be set are the domain name and the path by which a browser will send back a cookie. When you make any subsequent visit to a page for which you have a cookie set, its name and value are sent to the web server.

The default behavior is to send a cookie back to any page on the same domain that it was set from. By setting the domain and path, you can tell the cookie to be sent back to other subdomains or only to scripts in a certain part of the site.

The following header creates an email cookie that is sent back to any subdomain of lightwood.net, as long as the page requested is in the /scripts subdirectory:

 Set-Cookie: email=[e-mail]; domain=.lightwood.net;              path=/scripts 

Subdomains You can only set the domain attribute of a cookie to a variant of the domain from which the cookie was originally set, or to .yourdomain.com to indicate all subdomains.

This is a security measure to prevent some websites from being able to confuse others. For example, you cannot set a cookie that would be sent back to www.php.net from any website that is not hosted at php.net.

Accessing Cookies

The $_COOKIE super-global array in PHP contains all the cookies that have been sent to the current script. Cookies are sent back to the web server in an HTTP header, and PHP builds the $_COOKIE array based on this information.

You can access cookies in the same way that you reference posted form data. For example, the following statement displays the current value of the email cookie:

 echo $_COOKIE["email"]; 

If you ever feel that your cookies are getting in a bit of a mess, you can just create a script to dump them all out to screen so you can see what's going on. It is as simple as this:

 echo "<PRE>"; print_r($_COOKIES); echo "</PRE>"; 

Making Cookies with PHP

Although you have now seen how to create cookies by using HTTP headers, you will probably not use this method again because PHP contains a function that makes cookie setting much easier:

 setcookie("email", "[e-mail]", time() + 3600); 

Rather than the strictly formatted textual date shown in the header example earlier in this lesson, you specify the expiration date in setcookie as a Unix timestamp. This makes it easy to set a cookie that lasts for a fixed amount of time or until a date and time in the future.

Expiration Times The expiration argument specifies the latest date and time that a stored cookie will be transmitted. As time comparison is performed on the local computer, the actual expiration of cookies is determined by the local system clock and, if that clock is incorrect, is beyond your control.

The next two optional arguments are used to specify the domain and path for the cookie. If you want to set a domain and path but not an expiration time, you use NULL for the third argument:

 setcookie("email", "[e-mail]", NULL,            ".lightwood.net", "/scripts"); 

The final optional argument to setcookie is a flag that tells the browser to send the cookie back to the server only over an SSL encrypted connectionin other words, only for web pages with addresses that begin https://.

Password Cookies As handy as it may be to have a password stored in a cookie so that you can be automatically logged in to a website when you revisit it, this is very dangerous, even when the secure flag is set.

Cookies are stored in plain text and can be viewed simply by looking in the correct place on your hard disk. Malicious spyware programs exist that try to steal your passwords by searching through your cookies!

Deleting Cookies

There is no unsetcookie function to tell the web browser to delete a cookie. To stop a cookie value from being sent back to the web server, you use setcookie with an empty value and an expiration date that has already passed.

The following example unsets the email cookie by using an expiration value that is one hour ago:

 setcookie("email", "", time()  3600); 

Overwriting Cookies When unsetting a cookie or when overwriting an existing cookie with a new value, you must make sure the domain, path, and ssl-only arguments are exactly the same as when the cookie was originally created.