home—lects—exams—hws
D2L—breeze (snow day)
lect08a-cookies
cookies
chapter 9
From PHP Visual Quickstart Guide by Larry Ullman
Originally based on notes by Jack Davis (jcdavis@radford.edu)
As larger more complex web sites are being built the
limitation of http as a stateless protocol becomes a
problem. Web developers have no built in (html) method
of remembering data from one page of an application
to the next. This is a serious short-coming, e-commerce
systems, user registration and login systems, and other
online services rely on this functionality. Fortunately,
maintaining state from one page to another is fairly
simple using PHP.
- Cookies
-
(Note: we will not use cookies directly, in this class;
we'll use sessions. But sessions are built on top of cookies,
knowing how cookies work are a requirement for understanding sessions.)
- Cookies are a method for the server to store information about the user --
on the user's machine -- so that the server can remember
the user over the course of the visit or through several
web visits.
-
A cookie is just a key=>value entry
(just like a php array entry, or javascript object property,
or a java.util.Map entry, or json line).
-
It lives on the client machine,
and is provided by the browser when a request is made.
A PHP script can access
cookies by looking in the super-global $_COOKIE.
-
Example:
If a php script tells a browser to
setcookie('hamburger-price', 2.70) today,
and then the browser visits that same site next Tuesday,
the php can evaluate $_COOKIE['hamburger-price']
and get back 2.7.
-
In addition to the name/value pair, a cookie also has:
an expiration date, a domain, and a directory path.
Whenever a browser requests, a page, it attaches all cookie key/value pairs,
and sends those to the server — if the domain and path match.
So if you visit a page that performs a
setcookie('hamburger-price', 2.70, '/~ibarland', 'php.radford.edu'),
and later you visit
https://php.radford.edu/~ibarland/someDir/somefile.php,
your browser will attach the hamburger-price cookie.
But if you visit
https://php.radford.edu/~jcdavis/someDir/somefile.php,
the browser won't attach the cookie.
Similarly if you visit
https://rucs.radford.edu/~ibarland/someDir/somefile.php,
the browser won't attach the cookie.
(Note that setting a cookie for '.radford.edu' (note the initial .),
this refers to all machines within the radford.edu domain.)
Don't make two different cookies with the same path, but different domains
(one a superset of the other).
Different browsers may choose differently, which one gets sent.
(AFAICT: the more specific path wins; but for same paths with
two applicable domains, the first cookie set made wins.)
(It's not exactly advisable to make two different cookies with
the same name but different paths either, though that may not be enforceable,
e.g. /~ibarland and /~jcdavis may each contain
different scripts that happen to use the cookie “monster”.
Note also that if I set a cookie's path to be /,
then this is potentially a security flaw:
if somebody visits my script and I set a cookie secret-code-word
with server&path being radford.edu & /,
and then that person visits (say) radford.edu/~jcdavis,
his script will be sent the cookie that I had saved.
(He's a sly one, that jcdavis!)
Upshot: don't set the cookie's server&path to include URLs that others control.)
- It is essential to remember:
Cookies are created by the server, but stored on the client machine.
This explains why you have to call setcookie (rather than
just assign $_COOKIE['hamburger-price'] = ...):
You actually want to send cookies to the browser to remember (which is what
setcookie(…) does, and what assigning
to an array can't do).
It also explains why:
You must call setcookie before sending any other HTML —
the set-cookie info is sent to the browser as part of the http header, which
must be sent before any of the HTML data.
-
In Chrome (e.g.): Preferences… > Under the Hood > Privacy > Content Settings… Cookies > All Cookies and Site Data…, and then use the search-box
for (say) radford or amazon
- Cookies have gotten a bad rap because some users
believe cookies allow a server to know too much
about them. However, a cookie can only be used to
store information that you give it, so it's as
secure as you want it to be.
Tip:
- Creating cookies -
Cookies must be sent as part of the html header of the
html document sent from the server to the client, so they
must be created before output is written to the php created
response file.
setcookie(name, value, expiration, path, domain, secure, httponly);
- name - (required) cookie name
- value - (required) limited to 4KB of data, string
- expiration - (optional) used to set a specific
length of time for the cookie to exist. To set the
expiration time, you add time to the current time.
The time() function can be used to build this parameter,
setcookie('my-c-name','some-value',time() + 3600);
The setting expiration-time as 0 is a sentinel, meaning to
never expire.
If omitted, the default expiration is when the user closes their browser.
- path and domain (optional) parameters are used to limit a cookie
to a specific folder in a Web site (the path) or to
a specific domain, so this might be used to limit a
cookie to a subdomain, such as forum.example.com
Using the path option, you could limit a cookie to exist only
while a user is in the user folder of the domain:
setcookie('name','value',time() + 3600, '/user/');
- secure value (optional) dictates that a cookie should
only be sent over a secure HTTPS connection. A value
of 1 indicates that a secure connection must be used,
whereas, 0 indicates that a secure connection isn't
required.
setcookie(name,value,time()+3600,'','',1);
- httponly (optional) - can be used to restrict access to
the cookie (for example, preventing a cookie from being
read using Javascript) but isn't supported by all browsers.
- Script Example
lect09a-ch09-customize.php
- Deleting a Cookie -
Delete the existing cookies by sending blank cookies and complete the PHP code.
setcookie('name','',time()-600);
You can also set the timeout to 1 (second after the epoch-start);
note that setting it to 0 (or omitting) defaults to
timing out at end of browser session.
home—lects—exams—hws
D2L—breeze (snow day)