ITEC 325 2017spring ibarland

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

sessions
sessions
see also: Ullman chapter 9

We have discussed cookies, and in particular how setting a cookie "userID" can help us (the server) keep track of repeated visits from the same browser&user. (If you leverage that with having the server keep a database for each user, then this gives us history that can cross browsers.)

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

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)

• 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.
• 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.
• Note:
  Session name: the cookie-name, e.g. “PHPSESSID”.
  Session id: the value of that cookie, e.g. “'47af8helloall234__!'”
  
• Example of using sessions: page0.php

  This page 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.

• 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 re: sessions

Security Considerations

• How do we guard against people making up session IDs? Possible discussion: sites that use guessable session IDs. Make your session-key a (say) 256-character random string — chances of somebody guessing that at random are far smaller than you winning the lottery twenty times in a row.
  Happily, this is what start_session does for you by default.

• 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!)

• Real-life systems: Authenticate, and change the session-id with every interaction (so it can never by used twice): session_regenerate_id

Practical Issues

• Remember that sessions (and, cookies) span multiple windows/frames within the same browser.

  Imagine:

  1. A user searches your site for the best airplane fare for Tuesday.
  2. But they don't click “Buy” just yet; they open a second pane, and look for the best fare for Wednesday.
  3. They decide that they really do prefer the Tuesday flight, go back to the original pane, and now they finally click “Buy”.
  Don't sell them a ticket for Wednesday! You might happen to store (in $_SESSION) information about the most-recently-completed search, and that's fine. But hopefully all the flight info was also being conveyed through a form. This can be tricky if parts of the previous search were spread over multiple pages! Hidden input fields might still have their place, even in presence of sessions. (And of course, we automatically remind ourselves that hidden html input fields are subject to tampering by the user; for flight-request-info that's fine.)

  Btw, I don't think that cookies (and hence sessions) get shared between different computers¹, but it's conceivable that Chrome might allow sync’ing of cookies. Certainly, I personally synchronize my files between two different computers (which includes stored cookies).

  This means that if you have javascript which stores info client-side in files, your application should be robust against that file seeming to “disappear” halfway through a session. (Really, you should be somewhat robust against this regardless.)

• If you want to destroy a session via (say) session_unset, you still have to first call session_start. Why start a session if all you want to do is destroy it? Because session_start also initializes the session-id, which is needed for php to know which session to destroy.

• 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've completed any/all updates to $_SESSION values, 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.)

• If using sessions heavily in real life, be sure to browse PHP documentation for related functions, reading the real-world issues people have mentioned in the docu-wiki.

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

©2017, Ian Barland, Radford University Last modified 2017.Apr.05 (Wed)

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