In this article, we discuss the login portion of our banking application. The whole point of this application is to try to simulate an actual banking system, and at the same time to use all the knowledge that we've gained about Object Oriented Programming so far. I should also state that this is but one of many ways in which a banking application can be created. We will also be discussing some additional OOP concepts that we have not looked at yet.
The login method
To start off, both classes, the customer class and accounts class connects to the database server (MYSQL database server in our case) when they are instantiated. The constructor functions takes care of this very useful functionality. This is how its done in the customer class:
It would be better to have the database connection information stored somewhere else instead of showing it like this in the heading of the function for security reasons. Then it connects to the database server like so:
Then it selects the database that is going to be used:
If you are going to use a different database each time, please make sure to change where appropriate. What the constructor method does is to create a database connection resource that can be used anywhere in the class definition to run queries. To ensure that you can run queries in any of the other methods, it is important to first check if this resource is indeed set. For instance if you want to run a query in a method that is defined for the customers class you would do something like this:
What the method above does is to check if there is a connection established to the database server and then it returns true or false based on the outcome. Throughout our classes, we use this method to check if there is a database connection before attempting to run queries.
Below is a screen of the login form followed by some code that produces the form:
This is what the code for the login method looks like. In the above code this method is called in the following way:
The login method is located in the customer class and is responsible for presenting the login form to the customer. The form has two fields, one to take the customers username and another to take the customers pin number. The pin number is about four digits and the username is actually the name of the customer. The method starts off by defining a form tag like so:
Notice that in the action attribute of the tag the PHP_SELF global variable is used. This variable basically tells the form to submit the form data to the page from which it is called. This means that you can use this method in any script, and it will simply submit the form data. The next part of the code sets up the bank name:
Then we build the form element that actually takes the name of the customer:
Next we build the form element that takes the user's pin number:
Notice that we have set the type of field to password; this disguises the actual pin number of the customer and only dots appear when the customer enters it. Finally we create the submit button:
Note that it is always a good idea to include a hidden form field that you can use to check if the form is submitted or not. This is because sometimes users simply press the return button instead of the submit button on the form. This way, both scenarios are covered.
Now, once the customer submits this form, the following code takes care of the processing of the data:
The first few code lines of the code are very important because it is where all the classes are included and instantiated:
Instantiating a class, as discussed in the previous articles, transfers all of it methods and attributes to a variable that makes it easy for us to use in the wider application. For example to use any method in the customer class, we will not need to write this:
The next part of the code checks to see if the form has been submitted:
Then it validates the submitted form data. I cannot stress enough how important this part of form processing is. It is where most major attacks takes place so it is very important to validate your data. The first part of the validation process checks to see if the data that was submitted is empty and sets the appropriate error messages:
Then we check to see if the data is of the correct type. We expect two types
here, numeric for the pin number and string for the username. So it is easy
to check both with the
function or you can also use the
function to check for the name:
In the next section we will continue to look at the login code and also look at some of the other code that makes up the application.