Cookies, Sessions and Authentication

This page covers material from Ch. 12 in the text. Even swiped the title.

  1. Introduction. The problem of keeping your marbles.
    1. A PHP script runs, produces an output page and exits.
    2. Variable values are lost when the script exits.
    3. When pages are related, it is necessary to retain information between these executions.
      1. Executions can pass values to themselves through hidden form fields (Ch. 11).
      2. Cookies (this chapter) are another way for a script to have the web browser pass information to a later invocation. Cookies can be longer-lived, and passed to invocations other than the very next.
      3. Executions can retain data in the server file system using a database or plain files on the server.
      4. PHP provides sessions (this chapter) which allow PHP scripts to store information in the server where it can survive from one script to another.
      5. Use of the server-side methods usually requires use of a browser-side as well to identify which information is relevant.
        1. A hidden form field might contain an identifier to locate the database record for a shopping cart.
        2. Sessions typically use a cookie to store an identifier indicating which session to use.
    4. Frequently, web pages allocate resources (think: spend money, but there are many other possibilities). In that case, we want to know if the user really is who he/she claims.
    5. This is the authentication problem.
      1. Usually, the user sends an account an password.
      2. More sophisticated methods are beyond this course.
    6. Once authenticated, multiple pages will obey the allocation request.
      1. The authorization status must be passed from page to page.
      2. And must not be easily forged.
  2. Cookies
    1. Cookies were invented by the former Netscape Communications Corp. as a better solution for data retention.
    2. Technology
      1. Each HTTP message contains headers, which provide control info.
      2. Cookies use SetCookie and Cookie Headers.
        Client
        GET /some/url.php
        200 OK Set-Cookie: user=fred
        GET /some/url.php Cookie: user=fred
        Server
      3. The server asks the browser to remember a key/value pair when it sends a result.
      4. On the next request (only to the same server), it sends that info back.
      5. The server may assign an expiry date to the cookie, otherwise it is deleted when the browser is closed.
      6. The browser is not obligated to honor the Set-Cookie header, but most do.
    3. Using Cookies in PHP.
      1. setcookie specifies a cookie to be sent with the page generated.
        1. Only the name parameter is required.
        2. Must be called before any non-PHP sections, and before any echo.
        3. Set the expire for the cookie to last longer than the browser session. time() + 3600 lasts an hour. (Time is a Unix() time, seconds past the start of 1970, GMT.)
        4. The path and domain restrict where the cookie will be returned to. The domain can only be restricted within your own; one site cannot set a cookie for another.
      2. Cookies sent requesting a page appear in $_COOKIE['name']. Use isset($_COOKIE['name']) to see if it was sent.
        [ Cookie Example Source ]
  3. Authentication
    1. For our purposes, accepting and checking some kind of ID and password.
    2. HTTP Authentication.
      1. The HTTP protocol contains a password system using headers.
      2. The server requires login credentials from the browser, and the browser requests them from the user.
      3. The credentials are entered via a dialog generated by the browser, not through an HTML form.
      4. We'll not be using it.
    3. Using a form
      1. Usual way these days is to accept creds using a form.
      2. Input tag type password is like text, but shows stars when you type.
      3. Check the username/password pair against a database.
    4. Saving a password.
      1. Passwords must be stored on the server.
      2. Obvious target for hackers.
      3. Usually, the password is not saved, but instead a crypto hash is used.
        1. A cryptographic hash function is a one-way function, meaning it is very difficult to invert.
        2. If you know the correct hash, you can test a password by hashing it and comparing the results.
        3. But you cannot (in a reasonable amount of time) find the password from the hash.
          [ Some Hash Examples. Source ]
      4. Best practice is to use a slow hashing algorithm, with salt.
        1. Salt is some extra string added before hashing, so the same password will have different hashes.
        2. Text author does it himself, but easiest is to use password_hash. (This function may be newer than the text.)
  4. Sessions
    1. PHP allows scripts to create sessions, where they may store data on the server.
    2. By default, a cookie is generated which identifies the session.
    3. Use session_start to start using a session. Do this before generating output.
    4. Values are kept in $_SESSION['value'].
    5. When a user authenticates, this is often recorded in a session.
    6. Guessing Game With Sessions.
      1. [ Guessing Game Source ]
      2. Doesn't put the guess in the page source with a hidden field.
      3. Resumes even across window closing.
  5. [ Secret Example Source ]
    1. Allows you to keep some secret text protected by a password.
    2. Demonstrates creation and use of passwords stored safely on the server.
    3. A single PHP script generates one of four pages based on the state of the session.
    4. The state is stored in the session, and changes when the user submits a form.