PHP-HTTP and Sessions-Maintaining State

HTTP has no mechanism to maintain state; thus HTTP is a context-free or stateless protocol. Individual requests aren't related to each other. The Web server and thus PHP can't easily distinguish between single users and doesn't know about user sessions. Therefore, we need to find our own way to identify a user and associate session data that is, all the data you want to store for a user with that user. We use the term session for an instance of a user visiting a site where one or more pages are viewed. For example, a typical online shopping session might include 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.

 

At first, the typical PHP programmer tries to ignore the problem and find a workaround for it. The obvious workaround is to store all data on the client instead of on the server. This leads to forms with a lot of hidden fields or very long URLs. It becomes impractical with more than two files and more than one variable to save. An only slightly more intelligent method is to use cookies to store all information on the client side.

• You lose control over the data—as long as the user doesn't return to your site, you can't access the data. And worse, that data may be manipulated when you get it back. Ninety percent of all Web site defacing and breakings come from applications accepting tampered data from the client side and trusting that data. Do not keep data on the client. Do not trust data from the client.
• If you use GET/POST, the storage isn't persistent across sessions.
• If you rely exclusively on cookies, you have a problem because some users won't accept cookies—they simply disable cookies in their browsers.
• The data is hard to maintain because you need to save all data on every page. Each variable needs to be URL-encoded, added to a form as a hidden field or added to the URL, or saved as a cookie. This is difficult for a single variable such as the session ID, let alone dozens of variables!

Thus, the data needs to be stored on the server. Where exactly you store it isn't all that important; it can be in a relational database management system RDBMS, plaintext file, dBASE file, etc. Because a Web application generally already uses a relational database such as MySQL, this should be the preferred storage medium.

The typical PHP programmer tries to ignore the problem and find a workaround for it. The obvious workaround is to store all data on the client instead of on the server. This leads to forms with a lot of hidden fields or very long URLs. It becomes impractical with more than two files and more than one variable to save. An only slightly more intelligent method is to use cookies to store all information on the client side.

PHP has a built-in uniqid() function, but because it's based on the system time, it's not secure enough to be used for a session ID. However, you can combine it with a hash function and rand() to

 construct a truly 

srand((double)microtime()*1000000); // Seed the random number generator
$session_id = md5(uniqid(rand())); // Construct the session ID

By the way, md5(uniqid())—the same construct from above without a 
rand() call—would not be sufficiently random; because uniqid() 
is based on the system time, it can be guessed if the hacker learns the local 
system time of the server.