Home arrow PHP arrow Page 3 - Building an E-Commerce Site Part 2: Managing Users with Sessions

Primer on Sessions - PHP

This is the second article in a three-part series dealing with using PHP 4 and MySQL to make a comprehensive e-commerce storefront solution. This article covers session management within the store, user privileges, and a few security concerns.

  1. Building an E-Commerce Site Part 2: Managing Users with Sessions
  2. Assumptions and Requirements
  3. Primer on Sessions
  4. User Management and Privileges
  5. Step 1: Creating the Users Table
  6. Step 2: Extracting the New Scripts
  7. Step 3: General Script Changes from Tutorial 1
  8. Step 5: User Scripts
  9. Step 6: A Note on Security
  10. Step 7: Putting It All Together
By: Ying Zhang
Rating: starstarstarstarstar / 33
May 16, 2000

print this article



Before we begin, let's quickly go over the concept of a session and the reason we need it. It's hard (for me) to define what a session is exactly, so let's use an example that should be very familiar to you -- logging in to your computer and using it every day. After you log in, your computer knows who you are. Every action that you perform is done so with your name.

So what's so special about that -- we take it for granted every time we have to login to any system. What's the big deal with doing this on the web? Well, the web (or specifically, the HTTP protocol) is connectionless. That means each request made to a web server is independent of all the other requests. Whereas your computer keeps information about you in memory and knows when you log in and out, a web server doesn't. A web server simply waits for requests and sends responses.

Let's illustrate this a little bit:

Let's say we only have two people, John Doe and Jane Doe, accessing MyMarket, and their actions are like this:

  1. John looks at the product catalog.
  2. Jane looks at the product catalog.
  3. John adds an item to his basket.
  4. Jane adds an item to her basket.
  5. John goes to the checkout.
  6. Jane goes to the checkout.

Since HTTP is connectionless, each request is completely isolated from the other requests. So how does the server know who's doing what? How does the server know that actions 1, 3, 4 are from John, and actions 2, 4, 6 are from Jane? Well, to make a long story short, the web server doesn't have to know. It can continue on happily responding to requests, session management has to be done with the backend scripting language.

What we need is a way to group together requests by the same person into the same session. This is where PHP4's session management capabilities come in. It can group together requests made from the same source (eg. client's browser) into the same session, we have to provide the smarts to associate users with sessions.

In other words, PHP4's session management can tell us requests 1, 3, and 4 belong to the same session (call it session A). Our application has to know that session A is owned by John Doe.

{mospagebreak title=Session Management in PHP4}

PHP4 adds some session management functions that make our life easier when dealing with sessions. The ones we are interested in are:

  • session_start();
  • session_register();

session_start() is used to start up PHP4's session management capabilities; you need to call it before you use any of the other session functions. session_register() is used to tell PHP which variables to track in the session. A typical call to these functions would look like this:


This tells PHP to start up the session manager, and tells PHP that the variable called SESSION is a session variable. You can register as many session variables as you like, but I prefer to only register one session variable called SESSION, and anything I need persistent I put into this variable. For example, I like to say:

session_register("SESSION"); $SESSION["var1"] = 5; $SESSION["var2"] = 6;

instead of

session_register("var1"); session_register("var2"); $var1 = 5; $var2 = 6;

because after you register lots of session variables, you tend to forget what they were, well, at least I do :).

Anyhow, by now you probably want to see some code in action, so create a script called session_test.php somewhere accessible, and put into it:

<? session_start(); session_register("SESSION"); if (! isset($SESSION)) { $SESSION["count"] = 0; echo "<li>Counter initialized, please reload this page to see it increment"; } else { echo "<li>Waking up session $PHPSESSID"; $SESSION["count"]++; } echo "<li>The counter is now $SESSION[count] "; ?>

Fire that up in your browser, the first time you hit the page, it should say " Counter initialized, please reload this page to see it increment". Each time you reload it, the counter value should increment by one. You will also see the session ID. If it does, then hurray, your PHP4 session manager works :)

So how does this work? Well, when you call session_start(), PHP4 determines a unique session ID for the client. This session ID is an MD5 hash of something (not sure what), and it is stored as a cookie on the client's PC.

Now each time that client makes a request, PHP4 will read this session ID and load up the data for the session. When you call session_register(), you are telling PHP4 which variables you want kept in the session. Each page that loads up, the previous values for the registered variables will be reloaded, and each time the page ends PHP4 will save the values of the registered variables.

By default, PHP keeps track of the sessions in temporary files in the /tmp directory, take a listings and see for yourself:

You will see something like this:

-rw------- 1 apache web 10 May 7 15:27 sess_6dd9ea8e61cd49cd3ad6de -rw------- 1 apache web 10 May 7 19:49 sess_7d7f97afb6759948f554b00 -rw------- 1 apache web 6 May 9 01:00 sess_8ab78830e151add9d79b628 -rw------- 1 apache web 31 May 9 11:41 sess_a3058a6bb1baf57f565c384 -rw------- 1 apache web 30 May 9 11:42 sess_c379faad83ad3dc8ab6d22c -rw------- 1 apache web 6 May 8 01:00 sess_cd68a5054241aff1a8157c2 -rw------- 1 apache web 34 May 7 15:17 sess_cd97e41912b28c44cc0481b -rw------- 1 apache web 42 May 9 11:23 sess_d1285edd0c951c70b1aec17 -rw------- 1 apache web 30 May 9 11:42 sess_da93f6e19b6be01257d7a64 -rw------- 1 apache web 42 May 7 21:26 sess_e837123c1af78c538e89b47

Each one of those files is a session, let's take a look at one of them (note, you probably have to su to root to peek inside a session file). Tip: don't just cut and paste the following commands, you need to specify the name of a real file:

# more /tmp/sess_a3058a6bb1baf57f565c3844c8810f4b

You will see something like this:


Does that look familiar? It should if you've ever used the serialize() and unserialize() functions in PHP. If not, don't worry about it. Anyhow, I just wanted to illustrate how sessions were stored. You can rewrite the PHP session handlers to store sessions into a database or whatever else, but that's beyond the scope of this tutorial (but it's not hard at all).

>>> More PHP Articles          >>> More By Ying Zhang

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Hackers Compromise PHP Sites to Launch Attac...
- Red Hat, Zend Form OpenShift PaaS Alliance
- PHP IDE News
- BCD, Zend Extend PHP Partnership
- PHP FAQ Highlight
- PHP Creator Didn't Set Out to Create a Langu...
- PHP Trends Revealed in Zend Study
- PHP: Best Methods for Running Scheduled Jobs
- PHP Array Functions: array_change_key_case
- PHP array_combine Function
- PHP array_chunk Function
- PHP Closures as View Helpers: Lazy-Loading F...
- Using PHP Closures as View Helpers
- PHP File and Operating System Program Execut...
- PHP: Effects of Wrapping Code in Class Const...

Developer Shed Affiliates


Dev Shed Tutorial Topics: