Thread: Session Management Using PHP

Most of us use sessions on a daily basis while browsing the Web. But have you ever wondered how sessions are imp,lemented? The e-mail account we hold, the subscribed journal pages we read, the paid music channels we listen to-all these services use session management to identify their users. Session management provides two facilities: it protects the content from unauthorised access, and makes the same URL behave as per the requirements of the user.

Usually, most of us never care to think about what happens in the background when we enter our login credentials (user name and password). We probably consider this process quite trivial. In one of my recent projects to build a login-based set-up, I needed to create sessions to provide measured rights to the users. The problem that I considered trivial, began to bog me down. I went through a few difficulties while creating reliable sessions, and in the process learnt some lessons. Let me share them with you in this article.

The project was on the back burner for a while for the want of a reliable session management strategy. Most times, PHP session management silently failed and I could not make head or tail out of the problem Gater on, I found that disabling cookies in the browser made the PHP sessions fail). You can say I looked like Charlie Chaplin-doing all the serious work and coming out with laughable results. An implementation of sessions using a server-side database worked correctly for me and I was able to successfully finish the project. The post-mortem of the 'failure of PHP sessions' showed that clients that block cookies cannot engage in a session.

What's in a session?

A session means the duration spent by a Web user from the time logged
in to the time logged out-during this time the user can view protected content. Protected content means the information that is not open to everyone (like your e-mail inbox). The beauty of a session is that it keeps the login credentials of users until they log out, even if they move from one Web page to another, in the same Web service, of course.



From the point of view of a serverside programmer, the server verifies the user name and password obtained from the client and permits the client to create a session if the data is valid. On successful verification oflogin credentials, a session ID is created for the user, which should either be stored on the server or the client. Once the login information is stored, all subsequent pages identify the user and provide the requested information.

The two parts of this article (the second part will be published next month) explain two alternative strategies for creating sessions and explain the pros and cons of both. On the client side (about which we'll talk about in this issue), the session ID can be stored in a small file called a cookie. The cookie stores a name, a value, the server from which it originated, the time of creation, expiry time, etc. This file
is stored on the client machine with the permission of the browser. The browser settings affect the storage of cookies on the client machine.

Although the cookie-based strategy is simple, it comes with a few weak links. People might peep into the client machine, find the cookie and misuse the name-value pair to cheat the server, disguising themselves as authentic users. Hence, cookie-based sessions are not recommended for financial transactions, as they don't have the total assurance of privacy.

The second pitfall in cookie-based sessions is that a conservative user may block all incoming cookies. When the server sends a session cookie, it assumes that the client would store it. But, the client might reject the cookie for security reasons and thus hamper the formation of a session. This is what happened in my project. While some attempts to log in were successful, some were not. The reason being
that blocking cookies was hampering sessions.

To make session management independent of cookies, a database was created on the server to store the session information. Each page of the site included a status-checking script, which queried the database, checked the validity of a session, and permitted further access only if the session was valid. This solution worked well, and
I will present the procedure in the second part of this article.