Lecture 20 (12/5)

Same-Origin Policy, JSONP, CORS

Readings / Resources:

Lecture Notes:

Assignment 6

Due: Wednesday, Dec. 7

In this assignment, you will develop the ORM layer for our banking application. You will be provided with stub definitions for three classes representing customers, accounts, and transactions. These stub definitions are used to implement the RESTful interface used by your client-side interface code from assignment 5. You will use your assignment 5 solution to test your assignment 6 implementation. If you are unhappy with or did not complete assignment 5, you can copy my assignment 5 solution in order to test your assignment 6.

Setup

In order to setup assginment 6, do the following:

  • Create an “a6″ directory in your class web space.
  • Copy all of the PHP files found here into your a6 directory.
    • Each PHP file is represented twice: once with the suffix ‘.php’ and once with the suffix ‘-php.txt’. The two versions are identical and are provided to allow web-based access to the files. When you copy them to your a6 directory, however, the names of the files should end in ‘.php’.
    • Note that there is a subdirectory named ‘model’ that also includes several files. You should also create a subdirectory in your a6 directory called ‘model’ and be sure to copy the files from this subdirectory.

Completing the assignment

In order to complete the assignment, you should only need to modify the files in the model subdirectory. The files at the top-level implement the RESTful interface as documented in assignment 5. This interface relies on the classes defined in the model. All of the required methods have documented stub definitions. Your task is to provide an implementation for those stub definitions that matches the documenting comments. Each of the model classes includes a constructor that is private to the class and a forJSON method. You should not alter or modify these.

When the model classes are used by the RESTful interface code, the file ‘model.php’ is used to include the model classes. This file also properly sets up the DateTime class to use the correct timezone and calls “mysql_connect” and “mysql_select_db” in order to set up a connection to the database. This means that your code will not have to do this and that you can use the other PHP mysql library calls without worrying about setting up the connection. You should not need to modify model.php in
order to complete the assignment.

Although stub definitions have been created for all of the methods that the RESTful interface relies upon, you may need to create additional methods in the model classes in order to support your implementation.

In order to test your model implementation, you should be able to make a copy of your assignment 5 solution and simply change the base URL used to interact with the server-side back end to:

http://wwwp.cs.unc.edu/Courses/comp426-f11/<login>/a6

where <login> is your class login name. Be sure to make a copy of your solution and not modify your original solution since we may still be grading it. If you are unable to use your assignment 5 solution for any reason (i.e., it doesn’t work or you simply don’t like it), you are free to copy my assignment 5 solution found here. You will need to change the first line of ‘login.js’ and ‘account_view.js’ in order to set the base application URL as discussed above.

Database Details

Although you will not need to set up the database connection, you will need to interact with the database by issuing SQL queries and handling results. To do so, you will need to know the details of the database design. The database for our banking application is implemented as 3 tables:

  • a5_customer
  • a5_account
  • a5_transaction

Below are the column details for each account. The columns are listed in the order required for a SQL insert statement. Each table includes an id column which is an auto increment primary key for the row.

The a5_customer table has 5 columns:

id
The primary integer ID for the customer
first
The first name of the customer as a string (max 50 characters)
last
The last name of the customer as a string (max 50 characters)
email
The email login for the customer as a string (max 100 characters)
password
The password of the customer as a string (max 50 characters)

The a5_account table has 4 columns:

id
The primary integer ID for the account
name
The name of the account as a string (max 100 characters)
balance
The current balance of the account as a floating point number
customer_id
The id of the customer associated with this account. This is a foreign key for the a5_customer table.

The a5_transaction table has 6 columns:

id
The primary integer ID for the transaction
amount
The amount of the transaction as a float.
party
The name of the party to the transaction as a string (max 100 characters)
tdate
The transaction date as a SQL date type.
balance
The balance of the account after the transaction was posted as a float
account_id
The id of the account associated with the transaction. This is a foreign key to the a5_account table.

Lecture 19 (11/16)

SQL Continued, PHP MySQL, ORM

Readings / Resources:

Lecture Notes:

Lecture 18 (11/14)

SQL

Readings / Resources:

Lecture Notes:

Assignment 5

Due: Wednesday, Nov. 23

In this assignment, you will develop a client-side user interface for our banking application. You will need to develop two interfaces implemented as two different HTML files (along with any JavaScript and CSS files that you develop that they may need):

  • login.html
  • account_view.html

To create these interfaces, you will need to issue AJAX requests for application resources using the RESTful API described in the Application API section below.

login.html

The login.html interface should allow the client to provide an email address and a password. A button should also be provided that submits this information to the application’s authorization service (described below). Upon successfully authorizing the client, the browser should be redirected to the account_view.html interface.

NOTE: you can redirect a browser in JavaScript by setting the location property of the global window object. See http://davidwalsh.name/javascript-window-location for a simple tutorial.

account_view.html

The account_view.html interface should provide the client with the following information and capabilities:

  • The name and balance of the current account as well as a way of switching to a different account.
  • A list of transactions for the current account possibly filtered by one or more of the following criteria:
    • Start date – transactions before this date should not be listed.
    • End date – transactions after this date should not be listed.
    • Low amount – transactions smaller than this amount should not be listed.
    • High amount – transactions higher that this amount should not be listed.
  • A way to post a new transaction to the account. Customers should be able to specify the name of the party and the amount, but not the date. The date will be set by the server-side code.

If, while using the account view interface, access to account and transaction information is denied because you do not posses the correct credentials (i.e., you haven’t logged in), the client should be redirected to the login interface.

Application API

The base URL for the server-side of the application is:

http://wwwp.cs.unc.edu/Courses/comp426-f11/a5

All results are JSON encoded and the content type of the HTTP response will be set to “application/json”. All application resources can be accessed either using https or http (as long as you are consistent).

The following RESTful resources from the base path are defined:

  • GET login.php
    • This resource expects to receive two parameters:
      • email – The email address associated with the customer.
      • pass – The password associated with the customer.
    • On success, the result is the simple string “validated”. Furthermore, the server-side back end will remember the customer as the current customer for interpreting access to the other resources described below.
    • Access to this URL may generate the following error responses:
      400 Bad Request
      This error will occur if either parameter has not been provided.
      401 Unauthorized
      This error will occur if the password does not match the stored password for the customer. This error may also occur if the email address is not associated with any customer.
  • GET accounts.php
    • This resource does not require any parameters. On success it will return an array of JSON objects. Each object represents a different account associated with the current customer. Each account object will have the following properties:
      • id – A numeric account id
      • name – The name of the account
      • balance – The current balance of the account
    • If there is no current customer (i.e., you have not logged in yet) this resource will return a “401 Unauthorized” response.
  • GET transactions.php
    • This resource accepts the following parameters:
      • account_id – Required. Must be the account id from which you are
        requesting transaction information.
      • start_date – Optional. A date string appropriate for the PHP DateTime
        constructor. If specified, the result will not contain transactions
        the occur before this date.
      • end_date – Optional. A date string appropriate for the PHP DateTime
        constructor. If specified, the result will not contain transactions
        the occur after this date.
      • low_amount – Optional. If specified, the result will not contain
        transactions that are less than this amount.
      • high_amount – Optional. If specified, the result will not contain
        transactions that are greater than this amount.
    • On success, an array of JSON objects ordered by date will be returned.
      Each object represents a transaction and contains the following
      properties:

      • id – A transaction id
      • amount – The amount of the transaction
      • party – The party associated with the transaction
      • tdate – The transaction date as a string in ‘m/d/Y’ form.
      • balance – The balance of the account after the transaction
      • account_id – The account id associated with the transaction
    • This resource may generate the following errors.
      • 400 Bad Request – if the account id is not provided or if the account
        id provided is not associated with the current customer.
      • 401 Auauthorized – if there is no current customer (i.e., need to login)
  • POST transactions.php
    • This resource expects the following parameters (all are required):
      • account_id – Account id of the account to post the transaction to.
      • amount – Amount of the transaction to be posted.
      • party – The party associated with the transaction.
    • On success, a JSON object representing the new transaction is returned.
      The properties of this object are the same as described above.
    • This resource may generate one of the following errors:
      • 400 Bad Request – This is generated if the account id is not provided,
        if the account is not associated with the customer, if the party
        information is not provided, if the amount is not provided or is 0.0,
        or if there are insufficient funds in the account to post the
        transaction. You can tell the difference between these results by
        by looking at the content returned which will be one of the following
        JSON encoded strings:

        • No account id
        • Bad account id
        • Bad amount
        • Party name is empty
        • Insufficient funds
      • 401 Unauthorized – if there is no current customer (i.e., need to login)

Your interface should deal with errors gracefully by providing some indication of the error to the user and allowing the user to rectify the situation if possible (i.e., provide a party name, change the amount of the transaction, etc.).

Although not required, consideration will be given to additional interface functionality such as being able to sort transactions on different fields and paging transactions so that no more than a reasonable number show up at once.

Setting Up Test Data

Visit the page: http://wwwp.cs.unc.edu/Courses/comp426-f11/a5/model/setupCustomer.html in order to setup a test customer for yourself. This will obliterate all data associated with this customer (identified by the email address) and will create a new set of test data associated with that customer. Be careful not to step on each others toes (i.e., setup a customer for yourself to use associated with your own email address).

The test customer will have 3 accounts with an initial balance of $10,000. It will also randomly generate 200 transactions dated between 1/1/2000 and the current date.

Put all of your assignment files (i.e., HTML, JavaScript, CSS, etc.) in a
subdirectory of your class web space called “a5″.

Lecture 17 (11/7)

Database Primer

Lecture Notes:

Lecture 16 (11/2)

Security

Readings / Resources:

Lecture Notes:

Lecture 15 (10/31)

Cookies

Readings / Resources:

Lecture Notes:

Assignment 4

Due: Wednesday, November 2

For this assignment you will develop a RESTful interface for an on-line banking application. You should develop a separate controller for each of three different resource types:

  • Customers
  • Accounts
  • Transactions

Create three PHP files to act as controllers named customers.php, accounts.php, and transactions.php. Place all files in a directory named “a4″. You should support the following URLs and HTTP methods (NOTE that for all of the URL paths below, the base path to your class web space and the specific “a4″ directory where the files are located is assumed and is not shown in
the paths listed below).

GET /customers.php
Retrieves a JSON representation of an array of customer IDs
GET /customers.php/<id>
Retrieves a JSON representation of the customer specified by <id>. The JSON object should have the following properties:

  • first : First name of customer
  • last : Last name of customer
  • email : E-mail address of customer
  • accounts : Array of account IDs associated with the customer
GET /accounts.php/<id>
Retrieves a JSON representation of the account specified by <id> with the following properties:

  • owners : Array of customer ids associated with this account
  • balance : The current balance of the account
  • inception : The date the account was opened
GET /transactions.php
Retrieves a JSON representation of an array of transaction IDs associated with an account.
The following parameters are expected to be provided when the resource is requested:

  • account_id : ID of account that transactions are coming from.
  • start_date : Start date of period in which transactions occured. If not provided, the inception date of the account is assumed.
  • end_date : End date of period in which transactions occured. If not provided, the current date is assumed.
GET /transactions.php/<id>
Retrieves a JSON representation of a particular transaction with the given ID. The object should have the following properties:

  • date : Date of transaction
  • amount : Amount either credited (positive amounts) or withdrawn (negative amounts) from the account
  • party : Name of the other party to the transaction (i.e., who you either gave money to or got money from)
POST /transactions.php
Posts a new transcation into a particular account and retrieves a JSON object representation of the transaction as above. The following parameters are expected to be provided:

  • account_id : ID of account to which the transaction should be posted.
  • amount : Amount either credited (positive amounts) or withdrawn (negative amounts) from the account
  • party : Name of the other party to the transaction.
  • date : Date of the transaction (if not provided, current date should be assumed)

Your code should appropriately validate any URLs and parameters and generate unsuccessful responses as appropriate. For example, an attempt to retrieve the details of a customer that does not exist should result in a “404″ response. Amounts or dates that do not make sense should also result in an error. You should use the PHP built-in function json_encode in order to generate the JSON representations. You can use the AJAX Console to test your PHP scripts.

Your code should interact with the PHP classes defined in a4-model.php as demonstrated in class. You should make your own copy of the file in your “a4″ directory. You can use the AJAX console application demonstrated in class in order to test your controllers. Remember, because the code in “a4-model.php” does not actually store any data permanently, your controller for creating a new transaction will not result in a permanent change to the model.

HINT: When constructing JSON representations for dates, you will need to use the DateTime object’s “format” method to generate an appropriate string representation. Similarly, when receiving parameters that represent dates, you should create new DateTime objects that correspond to those dates in order to be able to compare them with any properties in the model that are represented as dates.

Lecture 14 (10/24)

PHP Object Model and Prototype AJAX

Readings / Resources:

Lecture Notes: