User Personalization with PHP: User Login / Page 2 | WebReference

User Personalization with PHP: User Login / Page 2


[previous]

User Personalization with PHP:
User Login [con't]

Some JavaScript

Then in the header section of the HTML code, we also have some JavaScript code. This code adds an additional layer of data validation at the browser level. Since JavaScript is a client side scripting language, we can use it to make sure that the user fills in all the necessary form fields before the data is passed to the PHP. This is both convenient for the user and resource saving:

So how does this code work? It has function called checkform() that checks if all the required fields in the form are filled in. If the field is found to be empty then the code displays a message box alerting the user to this error:

See Figure 2

The function itself is called when the user submits the form. The code goes through all three fields and checks each of them. If an error occurs, the focus is set on the related text field. If no errors are found, the function passes the form data on to the PHP code for further processing.

The Logout Script

The logout script simply closes a session. When the session is started, all of the session variables that were created by the login script are available to whichever script the session was started with. When a user logs out we need to destroy those variables and close the session. We start by opening a session:

Then we check if the username session variable is set:

If so, then it means that a session is open. We then start to destroy it by unsetting all variables and removing the session from the server using the session_destroy() function and sending the user back to the login page:


The Activation Script

Those of you who have registered with a blog site or any other discussion forum or website, will know that you usually have to enter an e-mail address and then you get an activation link, which you simply click to activate your account. Well, now you will get the chance to actually write such a script yourself. The script that we will create here will be generic in nature, meaning that you can change it to suit your needs.

After a new user registers, our registration script will send an e-mail message that will contain an activation link to activate their account. The reason why I chose this method of account activation is because it is one of the most secure ways in which we can communicate with a user. The e-mail address that the user provides has to exist and belong to the person that is actually registering with it. The link that the user sees will look something like this:

Below is the code for the activation script:

By the time that the user receives an activation link through their e-mail, the registration script would already have made a record of the user registering, meaning that a user ID is automatically created. Effectively, the user would already be registered except that the account won't be activated until the user clicks on the activation link. If you look closely at the activation link, two values are given: u and a_code. These values represent the user id and activation code respectively:

u=1&a_code=5844a15e76563fedd11840fd6f40ea7b

So where do those two values come from? The assigned values are generated by the registration script that actually sends the e-mail. The purpose of the activation script is to activate the newly registered user account. The code therefore starts by checking if the required parameters are included in the activation link. If the parameters are present, then we typecast the values. We can do this because we know that the u value should be an integer and the thirty-two character hash value should be a string:

If both values are what they are supposed be, then we test to see if they have valid values; the u value has to be greater then zero for it to be valid. Another useful test that you can make is to run a query to check if the value represented by the u parameter really exists in the database and if the account that it is tied to is activated or not. So you would do something like this:

$sql = "SELECT * FROM users WHERE uid = '".$u."' AND actcode = '".md5(0)."'";

If the query returns a record then the u parameter is valid, if not then someone has tampered with the values. This is just an added security measure since the activation link can easily be tampered with and as such should not be trusted.

The a_code parameter should contain a thirty-two character hash value. If it does not then the code above simple sets it's value to zero(it does the same with the u parameter). The next part of the code then checks if both parameters have correct values before activating the user account:

if(($u > 0) && (strlen($code)) == 32){

If both are invalid then a error message is shown:

echo "Your account could not be activated. Please check the link or contact the site admin";

To activate the account, the following code is executed:

$SQL="UPDATE users SET actcode ='".md5(1)."' WHERE uid = '".$u."'";
$res = mysql_query($sql) or die(mysql_error());
if(mysql_affected_rows() == 1){ //update successful echo "Your account
is now active. You can proceed and log in.";

Since there is already a record of the account, we simply update it to reflect its new status, then we print a message to show the user that the record has been updated.

Conclusion

Javascript form validation should only be used as an additional measure and not the main method of form validation as it is not reliable. Even in this day and age, some users do disable JavaScript in their browsers in which case you would end up with an application that is tremendously disadvantaged and vulnerable to attack.

Original: March 02, 2009


[prev]