CSE 134A Lecture Notes, May 2, 2001

CSE134A LECTURE NOTES

May 2, 2001

ANNOUNCEMENTS

The midterm will be on Wednesday May 16.

COOKIES

int setcookie (string name [, string value [, int expire [, string path [, string domain [, int secure]]]]])

This defines a cookie to be sent along with the rest of the header information. Cookies must be sent before any other headers are sent (this is a restriction of cookies, not PHP). This requires you to place calls to this function before any <html> or <head> tags.

All the arguments except the name argument are optional. If only the name argument is present, the cookie by that name will be deleted from the remote client. You may also replace any argument with an empty string ("") in order to skip that argument. The expire and secure arguments are integers and cannot be skipped with an empty string. Use a zero (0) instead. The expire argument is a regular Unix time integer as returned by the time() or mktime() functions. The secure indicates that the cookie should only be transmitted over a secure HTTPS connection.

Common Pitfalls:

If only the name argument is present, the cookie by that name will be deleted from the remote client.
Cookies will not become visible until the next loading of a page that the cookie should be visible for.
Cookies must be deleted with the same parameters as they were set with.

SESSION MANAGEMENT

The information here is taken from Session Handling with PHP 4 by Tobias Ratschiller at http://www.zend.com/zend/tut/session.php?print=1

Session management is a mechanism to maintain state about a series of requests from the same user across some period of time. That is, the term "session" refers to the time that a user is at a particular web site. The problem is, that HTTP has no mechanism to maintain state. Individual requests aren't related to each other. The Web server can't easily distinguish between single users and doesn't know about user sessions. Session management refers to the way that associate data with a user during a visit to a Web page. This tutorial uses the term session for a single visit of a user. For example, a typical online shopping session might include logging in, putting an item into the shopping cart, going to the checkout page, entering address and credit card data, submitting the order, and closing the browser window. PHP 4.0 includes native session management functions to ease the task of managing user sessions.

The "life" of a session refers to the amount of time the session is active. "Serializing" means the transformation of variables to a byte-code representation that can be stored anywhere as a normal string. Without the serializing feature, it wouldn't be possible, for example, to store PHP arrays into a database. Serializing data is very useful for preserving data across requests, an important facet of a session library. You can use serialize() and deserialize(), but note that in PHP 3 these functions don't work correctly on objects (classes); class functions will be discarded.

Serialize() returns a string containing a byte-stream representation of value that can be stored anywhere. This is useful for storing or passing PHP values around without losing their type and structure. To make the serialized string into a PHP value again, use unserialize(). Serialize() handles the types integer, double, string, array (multidimensional) and object in PHP 4.

PHP's session management library offers the key characteristics required of a session management library:

It stores session data on the server. Because the library uses different storage modules, you can keep the data in plain text files, shared memory, or databases. The exact location of data is not really important (as long the performance of the medium is sufficient).
It uses a cryptographically random session ID to identify a user.
It saves the session ID (and only the session ID) on the client side using cookies, GET/POST, or the script path.
If the user disables cookies, the application can use other means of session propagation.

To associate session data with a user, you need a session identity number: a key that ties the user to his data. PHP 4.0's session management frees you from the task of inventing session IDs, serializing and storing session data.

Starting a Session

A PHP 4 session is started either explicitly by session_start(), or implicitely by registering a variable for the session, using session_register(). Usually, you will call session_start() on top of the page, so that session variables are available to your script, and register variables to the session later in the script. It wouldn't make a difference though, if you registered your session variables with session_register() in the head of the script and left out the session_start() call - session_register() calls session_start() internally, if the session isn't started yet. When you start a session either way, the following happens:

PHP checks whether a valid session ID exists.
If there is no session ID, PHP creates a new ID.
If a valid ID exists, the frozen variables of that session are reactivated and introduced back to the global namespace.

Registering a session variable is done through the session_register() command. This allows you to create (register) variables which are stored throughout the session, and can be referred to during the session. All variables you want to preserve across page requests must be registered to the session library with the session_register() function. Note that this function takes the name of a variable as argument, not the variable itself. You can use session_unregister() to remove variables from the session, for example, when the user removes a product item from the shopping cart.

This is an example of a counter.

Start a session
Print the most recent value of the counter
Increment the counter
Register the counter

session_start();
print($counter);
$counter++;
session_register("counter");

Session_register() takes the name of a variable as argument, not the variable itself - this is easily confused, but the examples show the difference clearly.

It's as easy to handle session variables as it is to handle GET/POST variables. If you register a variable named foo, $foo is accessible automatically after calling session_start(). Because the serialize() function was improved in PHP 4, it's also feasible to treat objects (classes) as session variables.

Ending a Session

Session ending is not automatic, because it is difficult for the system to tell when the user is finished the session. Several commands help you control how the system determines when to end a session for a user.

You can force a session end with the command session_destroy().
If you propagate the session ID via cookies, the default cookie lifetime is 0, meaning that the cookie is deleted as soon as the user closes the browser. You can influence the cookie's lifetime with the configuration value lifetime.
You can use the gc_maxlifetime configuration directive to determine how long after the last access to this session the data should be destroyed. This is used because the server doesn't know whether the cookie still exists on the client side. However, performing such a cleanup of old sessions (called "garbage collection") on every page request would cause considerable overhead. Therefore, in tangent with the gc_maxlifetime, you should use gc_probability. This specifies with what probability the garbage collection routine should be invoked. If gc_probability is 100, the cleanup is performed on every request (that is, with a probability of 100%); if it's 1 as by default, old sessions will be removed with a probability of 1% per request.

If you don't use cookies but pass the session ID via GET or POST instead, you need to pay special attention to the garbage collection routines. Users might bookmark URLs containing the session ID, so you need to make sure that sessions are cleared frequently. If the session data still exists when the user accesses the page with the session ID at a later time, PHP simply resumes the previous session instead of starting with a new session, which may not be your intention. A value of 10 to 20 for gc_probability would better fit this scenario than the default value of 1.

You might ask yourself why PHP allows you to specificy a probability (gc_probability) which determines when garbage collection will occur, rather than a function which cleans up every n times. If PHP used a counting function, the server would need to track the number of opened sessions somehow. Using the probability function means that the server does not have to store counters for cleanup, which translates to cleaner and faster execution.

Session ID Propagation

PHP 4 sessions support the following methods of passing the session ID:

Cookies (default)
GET/POST
Hidden in the URL, either done manually or by automatic URL rewriting

Cookies are the default way to pass the session ID between pages. If you're happy with cookies, you don't have to worry about any special configuration. Another common way is to pass the ID is with GET/POST. Your URL would then be similar to script.php3?<session-name>=<session-id>. You can create such URLs by using the global constant SID:

printf('<a href="script.php?%s">Link</a>', SID);

Automatic URL rewriting is one of the very cool new features of PHP 4, allowing you to add the session ID to all the links within the page. To enable it, you need to configure PHP with --enable-trans-id and recompile it. Then the session ID in the form = will be added to all relative links within your PHP-parsed pages. While this is a handy feature, it should be used with caution on high-performance sites. PHP has to look at each individual page, analyze it to see whether it contains relative links, and eventually add the ID to the links. This obviously introduces a performance penalty. Cookies, on the other hand, are set only once, avoiding the overhead of URL rewriting.