jump to content

Assignments

Assignment 1: Using PHP as a Template System.

Make a simple web site with at least 3 types of pages and 2 instances of each type. All types shall share a common masthead, footer and navigation. Make a page controller for each page and set title, heading and other data in variables. Make a master template for every type of page, that in turn will include the smaller page parts. (All data can be considered safe for this exercise, making filtering and escaping unnecessary. But students must be told such practices are required further on…)

Assignment 1 Grading Rubric
Criteria Performance Quality Score
0 points 1 point 2 points
Functionality The template system does not work or is far from being complete. The template system has all basic functionality and is mostly complete. All required functionality is present and the solution is complete.  
Code quality No indentation, no comments or only insignificant comments. Variable names do not tell their intended usage. Resulting markup does not validate and is not semantic. File names are undescriptive and do not follow any system. Code is mostly indented and have some usable comments. Most variable names are descriptive. There are only a few validation errors in the resulting HTML. The HTML has all basic semantics correct. File names are fairly descriptive. All code is properly indented and well commented. Variable names show their intended usage immediately. Resulting markup is valid and semantic. ALl files have been put in different directories according to their intended usage and all file names are descriptive.  

Assignment 2: Language constructs.

  1. Use for-loops in PHP to generate a table containing a multiplication table. Alternate rows shall be colored using class names (for this exercise CSS 3 selectors are forbidden). Every cell containing the square of a number ( 1 x 1, 2 x 2, 3 x 3, etc) shall also have distinct backgrounds. The table shall be appropriately marked up with column and row headers and a caption. The page must be valid (X)HTML strict or valid (X)HTML5. Repeat the assignment using while-loops.
  2. Generate functions in PHP that will return parts of a page, e.g. the HTML head, a masthead, a sidebar or a page footer. At least some parameters shall have default values. Have a page accept a number, submitted through the get method. Using a whitelist testing approach and the switch language construct, set values on variables that gets passed to the functions and output the page. If the user omits the GET-variable or provides an unacceptable value an appropriate error message shall be delivered. Use a whitelist approach for indata filtering, using type and range checks.

The code in both sub-assignments shall be properly commented and demonstrate different ways of making comments, including a leading PhpDoc-block. The coding style must be according to the PEAR convention, or a named convention of significant importance within the PHP community (with reasonable exceptions depending on this project’s small size).

Assignment 2 Grading Rubric
Criteria Performance Quality Score
0 points 1 point 2 points
Functionality No multiplication table is produced. Functions do not return usable results. GET-data is not tested at all. The work has all basic functionality and is mostly complete, but a few things are lacking, e.g. alternating row colors, caption or headers. The switch case construct does not allow for more than 3 alternatives. GET-data is tested for type but not range. No usable error message is displayed. All required functionality is present in both parts of the assignment and the solution is complete and at leastt 4 different values can be used for the switch-construct. GET-data is carefully filtered and bad data results in usable error messages.  
Code quality No indentation, no inline comments or only insignificant comments. Variable names do not tell their intended usage. Resulting markup does not validate and is not semantic. File names are undescriptive and do not follow any system. No PhpDoc blocks at all. Code is mostly indented and have some usable comments. Most variable names are descriptive. There are only a few validation errors in the resulting HTML. The HTML has all basic semantics correct. File names are fairly descriptive. PhpDoc blocks are present on most files and on most functions, but do not include more than 2 types of tags. The code does not follow a named coding convention. All code is properly indented and well commented. Variable names show their intended usage immediately. Resulting markup is valid and semantic. All files have been put in different directories according to their intended usage and all file names are descriptive. PhpDoc comments are present on all files and all functions and include at least @author, @param and @return tags. A coding convention is followed within reasonable limits.  

Assignment 3: Characters, Strings and Arrays

Make an array, indexed with integers, containing at least 5 famous quotes, sayings or similar phrases. At least one phrase must contain characters not present in the English alphabet/US_ASCII. You must use UTF-8 for this assignment. Using a GET-variable chose one of these phrases and perform the following operations on it (always starting with the original string). Output the results in an understandable way.

  • Convert all letters to upper case.
  • Count the number of characters.
  • Remove all vowels.
  • Reverse the string.
  • Find the first 5 and the last 5 characters.
  • Convert the string to ISO-8859-1.
  • Extra hard: Reverse the words in the string, but keep their order.
  • Extra hard: Put emphasis (em) on every other word.
  • Extra hard: Truncate the string to max 15 characters followed by … Truncate on a word boundary, not inside a word.

Loop through all phrases and output them as a list of links, with GET-parameters, to make the selection described above really easy. Use a whitelist approach for indata filtering, using type and range checks.

Use PHP to sort the array. Use print_r() or var_dump() to display the result. (Note: This is intended to show basic awareness of these two functions for debugging purposes.)

Assignment 3 Grading Rubric
Criteria Performance Quality Score
0 points 1 point 2 points
Functionality There are less than 5 sayings in the array or not more than 3 described string conversions have been performed. No character outside of US-ASCII is being used. No control of the editor’s encoding setting is demonstrated. No looping to display the links. Array is not sorted. There are at least 5 sayings in the array. At least 4 string conversions are performed. UTF-8 is used. The length of strings are checked using a multi-byte encoding aware approach. A loop runs to output the links, which are usable. The array is sorted and the result is showed. There are at least 5 sayings in the array. At least 8 string conversions are performed. UTF-8 is used. The length of strings are checked using a multi-byte encoding aware approach. A loop runs to output the links, which are usable and nicely formatted as a HTML-list. The array is sorted and the result is showed.  
Code quality No indentation, no inline comments or only insignificant comments. Variable names do not tell their intended usage. Resulting markup does not validate and is not semantic. File names are undescriptive and do not follow any system. No PhpDoc blocks at all. Code is mostly indented and have some usable comments. Most variable names are descriptive. There are only a few validation errors in the resulting HTML. The HTML has all basic semantics correct. File names are fairly descriptive. PhpDoc blocks are present on most files and on most functions, but do not include more than 2 types of tags. The code does not follow a named coding convention. The GET-variable is checked for type, but not range. All code is properly indented and well commented. Variable names show their intended usage immediately. Resulting markup is valid and semantic. ALl files have been put in different directories according to their intended usage and all file names are descriptive. PhpDoc comments are present on all files and all functions and include at least @author, @param and @return tags. A coding convention is followed within reasonable limits. The GET-variable is checked for type and range. A usable error message is displayed if it is unaccepable.  

Assignment 4: Templates and Emulated Database Results.

Expand on assignment 1. Set data in a multi-dimensional array (emulating database results). Chose what “row” (inner array) to show with a GET-variable. All rows must have a title-field and a body-field containg at least 3 full paragraphs of text. Check for appropriate values (filter input) and html-escape the output, as if it came from an untrusted source, before putting it into the templates. If the GET-value is unacceptable, show an appropriate error page. Use a whitelist approach for indata filtering, using type and range checks. Loop through all “rows” in the outer array and ouput a menu with links to all, using the title field for link text.

Assignment 4 Grading Rubric
Criteria Performance Quality Score
0 points 1 point 2 points
Functionality The template is not populated with values from the array. No error page is showed if the GET-variable is missing or has an incorrect value. Pages do not emulate a real web site in design. No menu is showed. The template is populated with the correct data. An error page gets showed if it refers to a row that is not present in the array, but it does not use a correct HTTP-header. Pages have enough content to emulate a real web site. A workable list of links is showed as a menu. The template is populated with the correct data. An error page gets showed if it refers to a row that is not present in the array, but it sends a 404 HTTP-header. Pages have enough content to emulate a real web site. The menu is properly formatted as a list and styled with CSS to look like a menu.  
Code quality No indentation, no inline comments or only insignificant comments. Variable names do not tell their intended usage. Resulting markup does not validate and is not semantic. File names are undescriptive and do not follow any system. No PhpDoc blocks at all. Code is mostly indented and have some usable comments. Most variable names are descriptive. There are only a few validation errors in the resulting HTML. The HTML has all basic semantics correct. File names are fairly descriptive. PhpDoc blocks are present on most files and on most functions, but do not include more than 2 types of tags. The code does not follow a named coding convention. All code is properly indented and well commented. Variable names show their intended usage immediately. Resulting markup is valid and semantic. All files have been put in different directories according to their intended usage and all file names are descriptive. PhpDoc comments are present on all files and all functions and include at least @author, @param and @return tags. A coding convention is followed within reasonable limits.  
Security No checks on the GET-variable, no escaping of output. The GET-variable is checked but the test is incomplete. HTML-output is escaped using htmlspecialchars, htmlentities or checked using a library like HTML purifier, but care is not taken to handle characters outside of the US-ASCII range. The GET-variable is checked and the test is complete. HTML-output is escaped using htmlspecialchars, htmlentities or checked using a library like HTML purifier, and care is taken to handle characters outside of the US-ASCII range.  

Assignment 5: Mailing Data From a Contact Form.

Make a contact form, contaning a subject field, a textarea for the message, a “from” name field, a “from” email field, and at least two checkboxes to chose between possible recipients (whom to contact).

Upon form submission, the data should be sent to the URL of the contact page, but now handled by the script. Filter and validate the submitted data to see if the values are safe and accepable. If not, re-display the form, pre-filled with the submitted values, and appropriate error messages. Use a white list approach to check that the recipient is actually one of the persons listed in the form. If the data is good, deliver it to the recipient using PHP’s mail-function. Set appropriate headers. Display a results page.

When displaying the results or when re-displaying the form, prevent HTML and script-injections. For the highest grade use a mechanism, e.g. session variables, to prevent multiple submissions.

Assignment 5 Grading Rubric
Criteria Performance Quality Score
0 points 1 point 2 points
Functionality No mail gets sent. No appropriate feedback is given to the user when submitting the form, i.e. if it contains bad data or is lacking any required field it is simply showed as if it was the first time. Fields are missing in the form and/or some form fields are not handled at all in the script. Missing or badly filled in data results in error messages, but correct form data is not re-displayed and has to be entered again. The mail function is invoked, but the user is not alerted about the success, i.e. the return value is not checked. The actual mail contains a few clues about its origin, a reply field and a useful subject line. All required form fields present and are handled by the script. All required form fields are present and are handled by the script. If the form contains complete and correct data the mail function is invoked. The form contains useful error messages if showed after failing tests. The user does not need to fill in valad data again. The results page is useful and informative. The actual mail is formatted so the recipient immediately sees all relevant information about its origin and purpose, and includes a useful subject line and an appropriate reply-to SMTP-header, that also includes the real name of the sender. Multiple submissions are not possible.  
Code quality No indentation, no inline comments or only insignificant comments. Variable names do not tell their intended usage. Resulting markup does not validate and is not semantic. File names are undescriptive and do not follow any system. No PhpDoc blocks at all. Code is mostly indented and have some usable comments. Most variable names are descriptive. There are only a few validation errors in the resulting HTML. The HTML has all basic semantics correct. File names are fairly descriptive. PhpDoc blocks are present on most files and on most functions, but do not include more than 2 types of tags. The code does not follow a named coding convention. All code is properly indented and well commented. Variable names show their intended usage immediately.       Resulting markup is valid and semantic. All files have been put in different directories according to their       intended usage and all file names are descriptive. PhpDoc comments are present on all files and all functions       and include at least @author, @param and @return tags. A coding convention is followed within reasonable limits.  
Security No special measures are made to ensure that the application is secure. The POST data is checked for valid and useful values, but the tests are incomplete.       HTML-output, when showing the form again when it contains errors or on the results page is escaped using       htmlspecialchars, htmlentities or checked using a library like HTML purifier,       and care is taken to handle characters outside of the US-ASCII range.       The subject and the reply-to fields are checked for possible attempts to include SMTP headers and appropriate       measures are taken to prevent them.       Malicious characters, like null or vtab, are not allowed. The GET-variable is checked and the test is complete. HTML-output is escaped using htmlspecialchars, htmlentities or       checked using a library like HTML purifier, and care is taken to handle characters outside of the US-ASCII range.       All fields are checked for possible attempts to include SMTP headers and appropriate measures are taken to prevent them.       Recipient email addresses are not showed in the HTML-code (the check boxes) to prevent spammers from picking them up.       Malicious characters, like null or vtab, are not allowed.  

Final assignment

Develop a simple CMS or a web application of choice that includes the following features.

  • Storing, retrieving, altering and deleting information in a database (CRUD).
  • Form handling: Retrieving submitted data, validation, usable patterns for feedback on errors.
  • User authentication and session management, secure handling of passwords.
  • Separation of concerns: Information updates should not require coding skills. Design change should not require PHP coding skills.
  • Some separation of logic, e.g. through templating. (On a beginners course like this it is not required to use full MVC architecture or have a similar separation of logic.)
  • Demonstration of good programming practices.
  • PhpDoc generated documentation.
  • Input filtering and suitable escaping of output, depending on the situation.
  • File uploads.

The site shall be hosted on the web site provided by the instructor or a web hosting company. Publishing and securing the web site is part of the assignment.

Examples of applications that can be built for this assignment include:

  • A blogging platform.
  • A gaming or sports tournament site, where users can see game results, aggregate scores and comment on them.
  • A site for a company where it displays its products. (On-line shopping probably will be part of Server Side Scripting 2.)
  • A project management site with to-do lists, a simple calendar and messages.
  • A very simple community where users can have personal profile pages, a status line and send each other messages.
  • A site for a club, a church/mosque/synagogue/temple or an association, with information about activities.

You are required to work in project form, plan your work and follow a process, including setting goals, writing down intended features, do sketches about site design (simple wireframes) and site structure, data processing flow and database design. If you deviate from the plan, describe the reasons and evaluate options and consequences.

Optional features for higher grades:

  • Automatic sending of email, e.g. alerting the owner of new comments or letting users subscribe to discussions.
  • Creation of a feed, SVG-image or other XML-based data format.
  • Authentication against operating system supplied user data, e.g. LDAP and Active Directory, or the use of a single sign-on service.
  • Integration with a web service, e.g. pulling in an RSS-feed.
  • A script that check the server for required functionality, e.g. PHP-version and modules, PEAR-modules, MySQL-version and a populated MySQL Timezone database.
  • Installation SQL queries to build tables and populate them with initial data.
  • Full installation scripts.
  • Caching mechanisms.
  • Image manipulation in PHP, e.g. making thumbnails or adding text to images.
  • Pretty URLs i.e. the URLs should reflect useful information to the user, not to the CMS.
Final Assignment Grading Rubric
Criteria Performance Quality Score
0 points 1 point 2 points 3 points
End user/site maintainer functionality The solution is far from complete, features are missing. All application data is displayed, but data can not be added. The site has at least 3 different types of pages. The navigation between all pages works. A site redesign would require extensive rewrites to the PHP code. All application data is displayed and most of it can be added or altered by a user through forms. The navigation between all pages works and is robust. The web site contains at least 5 different types of pages as well as an administrative interface that covers a few tasks. Authentication is required for all administrative tasks. A site redesign would not require extensive rewrites to the PHP code. A complete web site can be run using the solution. Data can be inserted and altered by users having no coding skills. The web site contains at least 5 different types of pages as well as a complete administrative interface/possibilities for users to add content. Navigation is usable and consistent. Authentication is required for all administrative tasks. The site is fully skinnable, i.e. the php scripts do not lock site maintainers into a specific design or a rigid HTML order.  
PHP functionality Only a very small subset of PHP’s features or built in functions are used. PHP reports lots of errors when the script runs. A basic subset of PHP’s features or built in functions are used. PHP reports only notices, strict or deprecated errors when it runs. The solution shows a reasonable wide range of language features and built in functions. PHP reports only strict or deprecated errors when it runs, and only a few of those. The solution takes advantage of a wide range of language features and built in functions. No built in features are duplicated in userland code. The best tool for the job is used throughout, e.g. 5 similar str_replace calls can be replaced by one preg_replace or multiple similar if-elseif’s are replaced by switch-case. PHP reports no errors at all when it runs.  
Database functionality No more than two tables, no indexes, only very basic SQL-queries. Database queries are not evaluated or errors are dumped on pages. At least 3 tables, normalization is not intentional, some fields used for sorting or selection are indexed.       Some database queries are evaluated and possible errors are hidden from users. At least 4 tables, mostly normalized. Most fields used for sorting or selection are indexed.       Appropriate data storage types are used for most fields. There are few redundant calls to the database.       All database queries are evaluated, possible errors are hidden from users and unexpected replies result in usable       messages to the user. The database contains at least 4 tables and has a good design, with tables normalized to the 3d degree, except where       normalization is bad for web performance, in which case the student explains the reason for not having a normalized       database. Fields that are used for selection and/or ordering of results have indexes. Appropriate data storage types       are used for every field. Where SQL is the better choice, it is used instead of PHP, e.g. for setting the time to now,       subselects, ordering and counting the number of rows. There are no redundant calls to the database.       All database queries are evaluated, possible errors are hidden from users and unexpected replies result in usable       messages to the user.  
Code quality No indentation, no inline comments or only insignificant comments. Variable names do not tell their intended usage. Resulting markup does not validate and is not semantic. No PhpDoc blocks at all. Placement of braces, parenthesis, etc is erratic. Code is indented, although somewhat erratically and it has a few usable comments. Some variable names are descriptive.       The resulting HTML may have some validation errors. HTML elements are rarely misused in ways that differ from their       semantic meaning. PhpDoc blocks are present on some files, functions or variables,       but may lack tags. Placement of braces, parenthesis, etc is mostly consistent. Code is mostly indented and have some usable comments. Most variable names are descriptive. There are only a few validation errors in the resulting HTML. The HTML has all basic semantics correct. PhpDoc blocks are present on most files and on most functions, but do not include more than 2 types of tags. The code does not follow a named coding convention, but placement of braces, parenthesis, etc. is consistent. All code is properly indented and well commented. Variable names show their intended usage immediately and variable naming follows a clear pattern. Resulting markup is valid and semantic. PhpDoc comments are present on all files and all functions and include at least @author, @param and @return tags. A coding convention is followed within reasonable limits.  
Security Security measures are completely missing or very few. Most data submitted by users or external sources is filtered or escaped. Malicious characters, like null or vtab, are not allowed. Some restrictions have been made for folder permissions. All data submitted by users or external sources is filtered before being handled and escaped when being output. Application passwords, e.g. to access the database, are kept safely. User passwords are not stored in cleartext. Sessions are identified only through cookies and the session identifier is regenerated when there is any change in user permissions. Folder permissions are restrictive. All user submitted or external data is thoroughly filtered before being handled and appropriately escaped when being saved in database, output as (X)HTML or XML, sent as email, etc. Unsafe characters are removed and malformed UTF-8 is rejected. A whitelist approach is used whenever possible. Application passwords, e.g. to access the database, are kept safely. User passwords are not stored in cleartext. Sessions are identified only through cookies and the session identifier is regenerated when there is any change in user permissions. Folder permissions are restrictive and do not permit more access than absolutely necessary.  
Application structure Code is unstructured. Code duplication occurs frequently. All files are kept in the web root and files are not structured in folders according to purpose. File names are undescriptive and do not follow any system. Presentation logic is not separated from business logic in any meaningful way. Code is mostly structured but code duplication may occur a few times. Some file names are descriptive about their usage/contents. Files meant for inclusion are mostly kept out of the web root. Presentation logic is somewhat kept away from business logic. Code is cleanly structured. Functions are grouped according to purpose. Code duplication is very rare. File names are fairly descriptive about their usage/contents. All files meant for inclusion are kept outside of the web root. Files are mostly sorted according to usage in appropriately named folders. Presentation logic is mostly kept away from business logic. Code is cleanly structured. Functions are grouped according to purpose and most can be re-used outside of this project. No code duplication occurs. Only files that are supposed to be callable through HTTP are kept in the web root, all files intended for incusion are kept outside of th web root. All files have been put in different directories according to their intended usage and all file names are descriptive about their usage/contents and consistently named. Presentation logic is kept away from business logic.  
Process There is no structured process and no documentation. The initial plan is vague and do not list the full feature set of the application. Only one or two pages have wireframes or wireframes are sloppy. Deviations from the plan are not discussed. The initial plan and sketches give a pretty clear picture about intended design, features and data flow. Deviations from the plan are explained to some degree. The work is documented, but lacks detail. The student has set clear goals, made detailed sketches about site structure, page design and data flow. Any deviations from the plan are discussed in a way that shows technical knowledge and personal responsibility. Work is documented in detail, as in Today I worked on feature X… I experimented with the following solutions… and chose solution Y because… This is the final result… In doing this I learned that…  

Besides the points awared in the rubric above, an instructor may award points for the bonus features listed above. However, bonus points should not be used as a way to cover up mistakes made at the fundamental level. Soundness should be valued more than fanciness.