Design Requirements 3
4. Safety: Java has built-‐in memory management and exception handling and Java servlets inherit these features and provide a very robust and powerful web service
4.3.5.4 Login and Checking Pin Servlets
When checking a user’s login the input needs to be checked to see if it only contains alphanumeric characters. The reason this is done is to prevent malicious attacks on the database. By checking that the input is only alphanumeric the service can protect itself from SQLInjection attacks that would release details about the database. The input is also checked to make sure that valid input has been entered. If no password or username is entered then the login returns false. All SQLExceptions are caught and no details about the database or errors are revealed. When checking a pin code the input is checked to make sure its only contains 4-‐digits if anything else is input then check PIN will return false.
Notification System
4.3.6
Many of the scenarios discussed in Section 3.2 require for the user to receive notifications via SMS. There are many ways of sending and SMS from an application. A company called Clickatell offers multiple API’s for sending and receiving an SMS. Clickatell was the first service to offer global SMS delivery service from a simple web interface [35]. Their API can be accessed via HTTP/S, SMTP, FTP, XML or SOAP connections. In order to interact with the Clickatell API you first need a username and API key. Registration is free on their website and once registered you can purchase SMS bundles with the smallest denomination being 400 SMS’s for R136.00. This works out to 34c a SMS; this cost gets less as bigger bundles are purchased. The API connection chosen to send the notifications was the HTTP connection as this was the simplest to implement in the JAVA Servlets. The HTTP URL can be seen in Figure 21. The URL takes 5 parameters:
1. Your Clickatell username 2. Your Clickatell password 3. Your API ID
4. The mobile number of the recipient 5. The message to be sent
The mobile number can be in either international format, meaning it starts with the country code (South Africa is +27), or your Clickatell account can be set up to automatically convert to a specific country. The message being sent needs to be UTF-‐8 formatted to be sent via an HTTP request, meaning the string does not contain any spaces or punctuation marks. The URLConnection Java class is used to make the HTTP request. The response from the Clickatell server will be a specific id for that given request. The system is very responsive and most SMSs are received within seconds. One of the problems with sending SMS notifications is that a SMS is limited to 160 characters. Most of the notifications being sent are shorter than 160 characters but when sending the user a link to where the QrID barcode can be downloaded, the link is longer and will therefore need to be shortened.
http://api.clickatell.com/http/sendmsg?user=xxxxx&password=xxxxx&api_id=xxxxx &to=448311234567
&text=Meet+me+at+home
There are many online websites that can shorten a URL but not many offer an API for an application to do this. Bit.ly is one of these websites and offers this feature for free. All that is need is to register on the site and get a username and API key. Then same as with the Clickatell API a simple URLConnection is used to send the HTTP request. Bit.ly will return a shortened URL. Here is an example of a shortened URL bit.ly/qyUZnu, which redirects you to www.paymentportal.co.za. The bit.ly URL can be seen in Figure 22 and it takes 4 parameters:
1. Your bit.ly username 2. Your bit.ly API key
3. The long URL you wish to shorten 4. And the format of the response.
Figure 23 SMS New Card Notification
Now that the download URL has been shortened, all notifications are less than 160 characters and can be sent over SMS. In Figure 23 an example of an SMS notification can be seen. This notification is for a new card: it contains a link to where the barcode can be downloaded, the current balance and the card’s unique 4-‐digit PIN. One of the problems with using external web services is that the server is running off a lab PC and therefore behind the UCT firewall that caused problems trying to access external websites. For this reason and alternative hosting platform was needed.
http://api.bitly.com/v3/shorten?login=xxxxxxx&apiKey=xxxxxxxxx x&longUrl=xxxxx&format=txt
Moving PaymentPortal Server to Amazon EC2
4.3.7
It was decided that alternative web hosting would be needed due to the problem faced with having the server behind a firewall. The problem is that most web hosting plans don’t let you run a web application on them and therefore a virtual dedicated server would be needed. These are not cheap with the price starting at $30 a month. They then allow you to run your own software on the server. Amazon Web Services (AWS) offers a web service called EC2 (Elastic Compute Cloud) this allows you to run your own server in the cloud. AWS is a cost-‐effective, flexible and easy to use cloud-‐computing platform.
What makes EC2 ideal for this project is that you can customize every aspect of instance and virtual server environment, to suit your needs. You can choose what Operating System you wish to run and install all the software that is needed for your web application. It offers all the same functions as a physical server but at a fraction of the cost. You can even select the hardware that you require for your instance. AWS can give you a static IP that can be used to access your EC2 instances. What makes it even better is that you can have a single IP for a web application, even if the application is running on multiple instances. AWS will manage the redirecting of requests to the difference instances depending on the resources available.
A main feature of EC2 is its elasticity, meaning that as your web application grows in popularity more instances can be launched to handle the extra demand [36]. The capacity of your EC2 can be increased or decreased in minutes. It can even scale itself up and down depending on its needs. Administrators also have complete control of what is being run on each server.
There are currently five EC2 locations where instances can be run. There are two in the US, on the east and west coast, one in Europe and two in Asia Pacific. For this project it was decided that the Europe region would be the best suited. This is because it’s the closest to South Africa and will therefore keep the latency cost to a minimum. The exact cost in latency will be evaluated during the evaluation process.
AWS offers one year free access to their service allowing the user to run 1 instance with a max size of 10GB and 15GB of data transfer. This project will not require more than this. Even if the user goes over these limits the costs are very reasonable and only pay per unit used. The cost per hour of CPU time varies between $0.0.2-‐$2.10 pre hour depending on the resources being used. Data costs are also low with all incoming data being free and outgoing data costing between $0.05-‐$0.120 depending on the amount being used. Therefore as an example if your application requires 100 instances and consumes 1TB of data the total cost for the month will be less than $100 a month this same service would cost over $3000 if physical servers where hired and even more if they were purchased. This low starting cost makes EC2 the perfect solution for any Internet startup because of the low starting costs and the flexibility to increase capacity as the demand increases.
The first step was to get an AMI (Amazon Machine Instance), which is a prebuilt virtual machine. For this project an Ubuntu 10.04 instance was chosen as this is what the application was being run on previously. The selected AMI can then be booted up and the necessary software installed. The software requirements to run a PaymentPortal server can be found in the appendix. Once the instance is setup and running the next step is to deploy the PaymentPortal application. Web applications can be packaged in a WAR (Web application ARchive) file that Tomcat can deploy and setup automatically. But before the
WAR can be deployed the MySQL script needs to run to create all the tables needed to run a PaymentPortal Server.
Paymentportal.co.za domain registration
4.3.8
The default ports for Tomcat are 8080 and 8443 – these are not the default for a web server which are normally port 80 for HTTP and 443 for HTTPS. Changing Tomcat to use port 80 and 443 was causing problems with needing sudo permissions when starting the server. The solution to get around this was to edit the IPTables to redirect the port 80 incoming request to port 8080. The same was done with the HTTPS ports. This allowed the web application to be accessed from a web browser without entering the port. The domain paymentportal.co.za was purchased to make it easier to remember instead of the server’s IP address. Completing the form on “co.za” was all that was needed to complete the domain registration. The domain registration cost was R50 for one year. The PaymentPortal web application can be accessed via www.paymentportal.co.za.