How to use cookies and sessions in a shared domain with PHP

From Web Services Wiki

Jump to: navigation, search



You want to use cookies and sessions on the Stanford domain while maintaining privacy and avoiding interfering with the functionality of other sites.


There are a number of measures that may be taken to ensure that the cookies and sessions you use are not visible to other applications.


MySQL-based sessions

If you have access to MySQL, storing your sessions in a database is the best option. Visit Stanford MySQL Service to register your group, department, or service for database access. At this time Stanford does not support MySQL for individual user accounts.

MySQL-based sessions ensure privacy by storing all session data in a secure database. We suggest always storing sessions in a database on the Stanford domain for many reasons. Read more about how to set up and why to use MySQL-based PHP Sessions.

Session names

Each session is indexed by its name (which defaults to PHPSESSID). If you don't have access to a MySQL database, make sure to use a unique name for your PHP sessions, since they are otherwise shared throughout the domain. To change the session name for your site or application, put the following line of code in its configuration file.

// Using ini_set
ini_set("", "new_session_name");
// Alternatively, use session_name
$old_name = session_name("new_session_name");

Some open source web packages already have an option to change the name of the session in their configuration files. Make use of these features whenever possible.


Restricting the cookie to a certain path

By default, when using the setcookie function, each cookie is valid within the directory in which it was created. For instance, if a script is located at, the cookie will be valid in "test" but not in any directories below it. It is possible to override this functionality by setting the path manually. When cookies must be accessed in other paths, which is often the case, it may be tempting to set the path to "/", which makes the cookie visible to the entire domain. We advise against this and suggest setting the path to your application's root directory.

// Restrict cookie path
// This is a web path, not a local path, so if you want to restrict cookies to your application directory
// and your URL is
// then set the cookie path to "/group/my_group_name/myapp/" (cut off the domain)
define("COOKIE_PATH", "/~your_sunetid/cgi-bin/myapp/");
// Cookies expire in one month
define("COOKIE_EXPIRATION", time()+60*60*24*30);
// Set the cookie
setcookie("username", "john_doe", COOKIE_EXPIRATION, COOKIE_PATH);


Why should I be concerned?

Sites hosted at Stanford share the domain. Sessions and cookies are accessible to all sites on the domain if precautions are not taken. Imagine a scenario where two groups install open source blogging software which use the same name for sessions in their respective paths. When the administrator is authenticated, a session variable called "admin" is set to true. The administrator may then gain access to both sites by logging into just one. This example is one of many possible problems that may arise from not securing your sessions by using unique names or storing them in a secure database.

References - session_name - setcookie

Personal tools