Cookies and Sessions

Lecture Notes for CS 142
Winter 2014
John Ousterhout

• Additional reading for this topic: none.

Stateless applications

• Web servers are generally "stateless":
  • Web servers maintain no information in memory from request to request (only information on disk survives from one request to another).
  • Each HTTP request is independent; server can't tell if 2 requests came from the same browser or user.
• Statelessness not always convenient for application developers: need to tie together a series of requests from the same user.

Browser cookies

• Cookie basics:
  • The first time a browser connects with a particular server, there are no cookies.
  • When the server responds it includes a header that defines a cookie:

    Set-Cookie: session=0x4137fd6a; Expires=Wed, 09 Jun 2012 10:18:14 GMT
    

  • Each cookie is just a name-value pair.
  • In the future whenever the browser connects with the same server, it includes a header containing the name and value, which the server can use to connect related requests:

    Cookie: session=0x4137fd6a
    

• What's in a cookie?
  • Name and data.
    • Data size limited by browsers (typically < 4 KB).
    • A server can define multiple cookies with different names, but browsers limit the number of cookies per server (around 50).
  • Domain for this cookie: server, port (optional), URL prefix (optional). The cookie is only included in requests matching its domain.
  • Expiration date: browser can delete old cookies.

Sessions

• Cookies are used by the server to implement sessions:
  • A pool of data related to an active conversation (one browser instance).
• Typically the cookie for an application contains an identifier for a session.
• Web frameworks like Rails do most of the work of managing sessions and cookies:
  • Rails provides session, a hash-like object in which you can store anything you like
    • Data will be available in all future requests from the same browser.
  • Rails automatically checks for a session cookie at the start of each request:
    • Cookie exists? use it to find session data
    • No cookie? Create new session, new cookie
  • End of each request: save session data where it can be found by future requests.

• Managing session state:
  • Approach #1: just keep state in main memory
  • Approach #2: store session state in files on disk
  • Approach #3: store session state in a database
  • Approach #4: store session in cookie
    • Fine for small amounts of non-sensitive data
    • Can't use for sensitive data: malicious users can fabricate
  • Most frameworks allow you to control session storage:
    • Provide an object that saves and restores session data.
    • Rails stores sessions in cookies by default.
• Sessions have numerous security issues, which we will discuss later.