ITEC 325 2013spring ibarland

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

lect09c-session-concerns
sessions: practical issues

From PHP Visual Quickstart Guide by Larry Ullman
Originally based on notes by Jack Davis (jcdavis@radford.edu)

We have looked at how php includes session_start, which transparently gives you an array $_SESSION full of data from the last time the same person visited. Sessions are built on top of cookies.

• php docs

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

• 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 -- source-code not released to students, since it enables students to create popular RU pages that authenticate and surreptitiously log 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 (whose source you can't see) then does its own prompting 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 url 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 2013.Apr.01 (Mon)

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