ITEC 325 2012fall ibarland

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

lect08c-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

• 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 2012.Oct.19 (Fri)

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