1 Session management and maintaining state
Session management or state maintenance poses a challenge for any
language. This is because, in contrast to stand-alone applications,
server-side applications transfer data between servers and clients.
A server-side application does not have full control over the data
at the client's computer. A client can delete, modify or add to any
data. Therefore client-data cannot be trusted.
Sessions are created to minimise the risk of data corruption. All user
data is stored on the server and associated with a session ID.
Data retrieval is based on the session ID. A security check must be
performed on any data, which a user enters, before the data is stored
on the server. It is not necessary to perform security checks on
data that is retrieved from the server. This is in contrast to PHP
applications without sessions: in that case a security check must
be performed on user data every time the data is used!
The session IDs should be generated by the server and should be long
and complicated enough to deter users from manual tampering with the IDs.
Session IDs are passed from page to page either
by using hidden HTML form text or
by using the query string or
by using cookies (on the client computer).
The user data, which is associated with a session ID can be stored on
in a file
in a database.
This approach reduces the number of security checks that must be performed
on user data. Because users can modify their cookies (or disallow cookies)
and can modify hidden HTML form text or query strings, it is possible
for a hacker to break into another user's session.
This problem affects all server-side web languages, not just Perl and PHP.
For highly sensitive applications, other measures, such as encryption (SSL)
and password protection must be added.
1.1 Hidden Text - Exercise
1) Create a form that asks a user for his/her name and some comments.
Then create two PHP scripts that create a response. The first script
displays the information which the user has submitted ("Hello $name.
These are your comments: $comments") and asks the user whether he/she
really wants to submit the information. The second script is invoked
by the first one and displays "Thank you $name. Your comments
have been submitted: $comments".
To implement this add a form and hidden tags to the first PHP script,
<input type='hidden' name='hiddenname' value=\"$name\">
<input type='hidden' name='hiddencomments' value=\"$comments\">
The second PHP script retrieves these strings via
$name = $_REQUEST['hiddenname'];
$comments = $_REQUEST['hiddencomments'];
1.2 Cookies - Exercise
2) Use a cookie instead of hidden text in the previous exercise.
The following code in the first PHP script sets a cookie.
$cookiedata = $name."|".$comments;
setcookie("nameandcomments", $cookiedata, time()+3600);
Note: the cookie must be set at the very beginning of the PHP script before
any other HTML code or header information is generated. Even blank space
at the beginning of the file can create a problem!!!
The second PHP script retrieves the cookie similarly to retrieving
$array = preg_split('/\|/',$_COOKIE['nameandcomments']);
$name = $array;
$comments = $array;
More information about
1.3 Using Sessions
3) Use PHP session
handling functions for the previous exercise. (In particular,
have a look at the
examples for session_start or
1.4 Hit Counter - Exercise
4) Create a file that contains
only the number "0". Your PHP script must open that file for reading;
read the first line of the file into a scalar variable; increase the
number by one; close the file; open the file again for writing (not
appending); write the number to the file; close the file.
(On Unix: because of permissions, first, you need to create and save the file
manually. Then you need to change the file permissions to 666 on the
2 Optional: Password protected pages
Access to web sites on an Apache Server can be controlled using the
HTACCESS files. Two files are involved in access control: a
.www-password file is created and saved in a directory above the
public_html directory. Any directory under the public_html
directory can then be protected by saving a .htaccess file in
the directory. It should be noted that htaccess only encrypts
the password but not the pages. Therefore it does not provide high
level security. Furthermore, htaccess does not protect your files
from being viewed by other Unix users on the same computer.
2.1 Optional exercise
Create a password protected directory under your public_html
directory. Specific instructions:
Go to your top level directory and type
htpasswd ~/.www-password remoteuser
at the Unix prompt. You can replace remoteuser with
a login name you want to use for your pages. Type in a
password when prompted. Note that this should be a new password,
different from any password you are using for other purposes.
The .www-password file must be readable by others.
Create a new directory under public_html. Go to the directory.
Create a file called .htaccess with the following content:
AuthName "Password Required"
<Limit GET POST>
require user remoteuser
where yourmatricnumber is your matric number
and remoteuser is the same name you used above.
Change the .htaccess file to readable (chmod 644 .htaccess)
If you view any html from that directory through your browser,
you should now be prompted for a username and password.