HTTP Session Management

Problem

HTPP is a sessionless protocol. Each GET request is handled by

• Open a connection to the Web server
• Download the document
• Drop the connection

HTTP 1.1

HTTP 1.1 attempts to solve some problems caused by this

• An open connection may be kept open instead of closed
• Requests from the same browser may reuse this connection instead of starting another one
• The connection is closed after a short period of inactivity e.g. 30 seconds
• This can double transfer times for some pages
• It doesn't answer the session management problem

Session management

• Applications maintain state
• Distributed applications may maintain state in each distributed component
• Web applications are expected to maintain state
• Typical Web application: shopping cart, where the server is expected to keep a list of items in the cart, and present this list on demand
• Web support for state is poor

Stateful server

In a client-server application, the server may keep state information

Stateless server

In a client-server application, the server may be stateless, with the client keeping state

Static Web documents

Neither side needs to keep state - HTTP 1.0 is designed for this

CGI Applications

• CGI applications run for the duration of an HTTP session
• State only exists for the lifetime of the CGI application - the HTTP session

Web Applications

• State must be maintained across CGI applications
• Requires the browser to maintain state information
• The browser cannot keep all of the server state - typically it keeps and returns a key for the server
• The key should not contain sensitive information such as credit card numbers

State information

A browser can keep state information in

• Cookies
• Hidden form fields
• URL rewriting
• Challenge/response

Cookies

• Cookie are passed at the HTTP layer
• HTTP format is Set-Cookie: cookie-value
• Cookies are sent from the server to browser and returned from browser to server
• Cookies have
  • a lifetime
  • a domain
  • a flag to return on secure or non-secure channels

Passing cookies from server to browser

• Cookies will be passed on the wire in the HTTP header
• Cookies may be passed from an HTML document to the HTTP layer by

  
         ...
        HTTP-EQUIV="Set-Cookie: ..."
        
        

• Cookies may be passed in a Perl CGI object by e.g.

  
        $cookie = $query->cookie(-name=>'sessionID',
                                    -value=>'xyzzy',
                                    -expires=>'+1h',
                                    -path=>'/cgi-bin/database',
                                    -domain=>'.capricorn.org',
                                    -secure=>1); 
        

Retrieving cookie from browser

• The cookie value can be retrieved by e.g. Perl code

  
        $cookie = $query->cookie(name=>'sessionID');
        

Problems with cookies

• Some users turn off cookies for privacy reasons
• Cookies expire after a while

Hidden Form Fields

• Pass the session key through in a named hidden field

  
        <form>
        ...
        <input type="hidden" name="session_key" "value="...">
        </form>
        

• Retrieve the session key through its name

URL rewriting

• A URL for a script can look like

  
        http://host/path/script/extra_info
        

  The extra_info is a '/' separated set of fields.
• Note that this is different to the typical script arguments of

  
        http://host/path/script?extra_info
        

• The two can be combined

  
        http://host/path/script/extra_info?even_more_info
        

• The stuff following the '/' is given in PATH_INFO
• The stuff following '?' is given in QUERY_STRING
• e.g. the request

  
        http://localhost/cgi-bin/test-cgi/abc/def?ghi
        

gives

      REQUEST_URI=/cgi-bin/test-cgi/abc/def?ghi
      SCRIPT_NAME=/cgi-bin/test-cgi
      PATH_INFO=/abc/def
      QUERY_STRING=ghi
      

• To use this, make the ACTION part of a Form include the session key as the PATH_INFO e.g. (Perl)

  
        print "<FORM ACTION=\"http://localhost/cgi-bin/test-cgi/abc/def\">";
        

Challenge/Response

• Refuse the HTTP request unless it is accompanied by a valid user id/password pair
• Then the REMOTE_USER_AGENT environment variable will contain the user id of the user
• This will be covered later in Security

Challenge/Response Plus/Minus

• Only method to identify user completely
• From the user viewpoint,
  • requirement to register with each new site
  • same user id can't be used across all sites (may already be taken)
  • different password rules on different sites
  • an exploding mass of user ids and passwords linked to sites