ITEC 325 2012spring ibarland

home—lects—exams—hws
D2L—breeze (snow day)

lect09a-ch09
cookies and sessions
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.

Self-assessment: Why does the following not print out 2.50?

<?php
  // before any html has been printed:
  setcookie('hamburger-price', 2.50);
  ?>

  ⋮
  <p>
  The going rate for hamburgers is $<?php printf("%.2f", $_COOKIE['hamburger-price'] ); ?>.
  </p>
 

Sessions

• Sessions: Another way to add history to the state-less HTTP approach. Recall that we've been battling this problem in several different ways now:
  1. Single page, no state.
  2. Using POST/GET to pass state from one page to the next: add info to URL
  3. Using cookies: the browser passes a (variant) GET argument with a serial number
  4. Writing a file server-side (perhaps along with previous technique)
  5. sessions: an automated way of doing the previous: create/restore an array on each visit (using a file kept server-side, and client-side a cookie so the server knows which stored file should be used for a given HTTP request)
  How do you use sessions in php?
  • The session_start function either:
    • Starts a new session (by sending a cookie — therefore session_start must be called prior to any HTML being sent!)
    or it
    • Resumes the current session (looking up $_COOKIE['PHPSESSID'], and using that to find an existing filename created/saved on a previous visit.)
  • When a session is started, a random session ID is generated and a cookie is sent to the Web browser with a name of PHPSESSID and a random value.
    (Aside: how do we guard against people making up session IDs? Possible discussion: sites that use guessable session IDs. )
  • Once the session has been started, a session variable can be created by assigning values to the $_SESSION array:
    

    $_SESSION['first_name'] = "Marc"; $_SESSION['age'] = 35;

    PHP writes data to a temporary file stored on the server.
  • An example that sets a session and a cookie; leads to a page that unsets the cookie (but not the session); which leads to a page that stops the session too. lect09a-ch09-cookies-sessions-0.php
  • lect09a-ch09-login.php
  • To delete a session variable you must unset the value in the session array.
    unset($_SESSION['first_name']);
    
  • To terminate a session (e.g. user logs out), there are three things that must be done (!):
    • Destroy the contents of the $_SESSION array in memory. Use session_unset, since it's a superglobal.
    • Destroy the info saved on the server's disk. Use session_destroy.
    • Finally, destroy the cookie associated with the session: setcookie( session_name(), '', 1, '/' )

      Gotcha: setcookie sets a cookie relative to the current directory, but the session cookie (by default) is relative to root. So to destroy the session cookie, you must pass '/' (by default) as the 4th argument to setcookie.

      Better, rather than assuming that session-cookies use / as the cookie-path, you should look up what the path for session-cookies is, using session_get_cookie_params:

      $myParams = session_get_cookie_params(); echo "The default path of cookies is ", $myParams['path']; print_r($myParams); setcookie( session_name(), '', 1, $myParams['path'] ); // note that sadly, php doesn't let you just do this in one line: // setcookie( session_name(), '', 1, session_get_cookie_params()['path'] ); // Syntax error!

  • php docs

  • Gotcha: session_start() puts a write-lock on the session file, so any other process trying to access it will block. (In particular: that 'other process' might be yourself, via an included-file which is also doing a session_start()!) One possible workaround (and good practice regardless): As soon as you're done updating any persistent values to $_SESSION, call session_commit. This writes and closes the data file, although it doesn't unset data in memory so you can still refer to $_SESSION. (Just remember that any later changes made to the array are no longer being committed, and because you've given up the lock others might be updating the file w/o you seeing any changes. You can apparently call session_commit again later, though presumably if some other process is accessing the file it may block and then it will overwrite the other file's changes.)

  • Self-understanding quiz: If we set $_SESSION['previouslyGaveMeCorrectPassword'] = true, is this easibly forgable by somebody else's browser?

  • IMPORTANT: If your session allows access to any secure information (for instance, once a user successfully types a password, you set $_SESSION['loggedIn'] = true), you want to be sure that no eavesdropper is (or was) able to ever see what the session-cookie's value is. Since cookies are sent by the client, we need to make sure the session-cookie is tagged as secure.

    But we don't create that cookie ourselves! We'd just called session_start, which takes no parameters. Alas, we have to set a preference before setting cookies:

    php_ini('session.cookie_secure',true)

    
    (I wish session_start allowed a flag, and also that it just made secure sessions the default!)

  • Note:
    Session name: the cookie-name, e.g. “PHPSESSID”.
    Session id: the value of that cookie, e.g. “'47af8helloall234__!'”
    
  • Real-life systems: Authenticate, and change the session-id with every interaction (so it can never by used twice): session_regenerate_id

  • IT-AUTH -- not released to students, since it enables students to create popular RU pages that authenticate and surreptitiously record each user's password.

    The solution is clever: Your page has a form that submits to https://php.radford.edu/~it-auth/vsp09/login.php. Your form passes in two strings (via hidden inputs, presumably):

    • an input url (whose value is the URL to go to after attempted authorization),
    and
    • the input cname (whose value is the cookie that will be set upon success).
    The it-auth page (which you can't see) then prompts for name and password, and if they match, that it-auth page will call setcookie, using the name you provided it! It then forwards back to the page you designated; your page can then check for that cookie name and know whether authorization succeeded.

    Don't tempt an honest man.

    To be effective, you'd better use a cookie-name that can't be guessed — in particular, if I use your site and then check my own cookies, hopefully I won't be able to look at that cookie name/value and guess what somebody else's cookie name/value is!
    https://php.radford.edu/~it-auth/vsp09/tutorial.php

home—lects—exams—hws
D2L—breeze (snow day)

©2012, Ian Barland, Radford University Last modified 2012.Mar.26 (Mon)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu