PHP Assignment ( Due May 14st, 2018 by 11:59pm)
Background
This assignment is designed to give you some hands on experience
in Web based scripting languages. You will get practice
implementing PHP scripts in a web environment.
These problems are designed to give you experience in the
following areas:
- Input processing & validation
- Dynamic page generation
- Generation, storage and display of data from web sources
- Regular expressions
- Custom sorting
- Handling file uploads
Some general guidelines for the problems:
- Your code should have some comments. At a minimum you should have comments
indicating the author and some comments as to what the
major parts of the script are doing.
-
Since your projects will need to be graded from within a web
browser, a common browser needs to be specified as the target
environment. For this assignment, your project will be tested
the latest stable release
of Google Chrome.
This assignment will be graded directly through a web browser, and examining code stored in your public directories on GL. Do not modify any of the files after the deadline.
Directory Structure
This project will make use of the directories that were created by the setup script for the JavaScript project. You should already have the following directories:
/afs/umbc.edu/users/b/u/bubba1/home
— This is the root of your GL account (i.e. your home directory).
/afs/umbc.edu/users/b/u/bubba1/home/swe2018/
— Anything put in this directory can be viewed on the swe webserver. For example if you put a
file called foo.png
in your swe2018
directory, then you could access it online at http://swe.umbc.edu/~bubba1/foo.png.
/afs/umbc.edu/users/b/u/bubba1/home/swe2018/cs433/
— This is the sub-directory created for you to put all of your assignments under.
/afs/umbc.edu/users/b/u/bubba1/home/swe2018/cs433/web/
— This directory houses 3 subdirectories called p1
,
p2
, and p3
. You will only be using p1
and p2
for this assignment.
/afs/umbc.edu/users/b/u/bubba1/pub/cs433/read-only
— A directory that is read-only by the web server outside of your swe2018
directory
/afs/umbc.edu/users/b/u/bubba1/pub/cs433/read-write
— A directory that is both readable and writable by the webserver outside of your swe2018
directory. You are going to want to store your script data in this directory
Important Notes
There are some additional files & directories created by this script
— do not delete, rename or re-chmod any of them.
No course-related code be placed outside of the p1
or
p2
directories. Doing so will
be treated as a violation of academic integrity and will be dealt with
accordingly.
Though PHP scripts run as a web-server user, you should still
take care to prevent someone from taking advantage of errors in
your script to gain unauthorized access to files/resources. For
example, if you ever build up a file name based on user input,
you better be sure that file is constrained to a given directory
(e.g. read-only
or
read-write
).
PHP scripts should be set with the following permission
— chmod 604 script.php
.
JSON/Ajax Calendar Back-End (40%)
Task
You are to implement a script which will respond (in JSON) to
Ajax requests. The provided HTML and JavaScript front-end will
manage a web-based calendar. Your back-end script will need to
respond to perform 3 different operations...
- List all events (starting/ending within or spanning) a given time range
- Create an event
- Delete an event
The requirements for this problem are:
- Create a script called
events.php
and place it in your swe2018/cs433/web/p1
directory.
- Support the following 3 request/response types...
Request/Response
Notes:
-
It is critical that you follow these naming
conventions in order for the provided front-end JavaScript to
work correctly.
-
The following JSON responses have been formatted for easier
reading. Your actual JSON output needn't be neatly
formatted/indented.
List Events
If the user requests the events.php
script by
way of an HTTP GET, then the script shall
return a list of all saved events as a JSON-encoded response.
The parameters passed via the GET request are…
-
start
— the beginning time (an integer) in
seconds of the range
in UNIX
time
-
end
— the ending time (an integer) in
seconds of the range in UNIX time
-
_
(an underscore) — the FullCalendar jQuery
plugin also sends an underscore parameter where the value is
the current time stamp. This is
a work-around
for some browsers (read older versions of “MSIE”)
to force non-cached responses.
This request returns all events within the given range like so...
[
{
"id":"4f946d81b1f3f",
"title":"Friday the 13th",
"start":1334289600,
"end":1334375999
},
{
"id":"4f946e3a45b3c",
"title":"Last Day of Classes",
"start":1336708800,
"end":1336795199
},
{
"id":"4f946fc11ac99",
"title":"Out of Town",
"start":1333684800,
"end":1333943999
}
]
As you can see, the results returned are an array of objects representing calendar events.
Each object contains the following 4 fields...
id
— a unique id (a string) which is generated for each object
title
— the title (a string) of the event (can be multiple events with same title)
start
— the time (an integer) in seconds representing the start time of the event
end
— the time (an integer) in seconds representing the stop time of the event
Create Event
If the user requests the events.php
script
using an HTTP POST with the
action
parameter's value set
to create
, then the script shall save the event
using the following post data…
title
— the title (a string) of the event
start
— the time (an integer) in seconds representing the start time of the event
end
— the time (an integer) in seconds representing the stop time of the event
When performing a create, the script shall return a JSON-encoded
response indicating the success/failure of the action. For
example...
{
"result":false,
"message":"YOUR ERROR MESSAGE HERE"
}
This response consists of the following fields:
result
— indicates (via a boolean) the success (true) or failure (false) of the create operation (required for both success/failure)
message
— the message (a string) indicating the underlying error if any (required only on failures)
Delete Event
If the user requests the events.php
script
using an HTTP POST with the
action
parameter's value set
to delete
, then the script shall remove the event
using the following post data…
id
— the unique id (a string) assigned to
the event to delete
Same as the create action, the script shall return a
JSON-encoded response indicating the success/failure of the
action. For example…
{
"result":false,
"message":"YOUR ERROR MESSAGE HERE"
}
This response consists of the following fields:
result
— indicates (via a boolean) the success (true) or failure (false) of the create operation (required for both success/failure)
message
— the message (a string) indicating the underlying error if any (required only on failures)
Working Demo
A sample version of this script can be found at:
https://swe.umbc.edu/~bwilk1/cs433/web/p1/.
Provided Files
For this problem, I've provided you the HTML/CSS/JavaScript front-end consisting of the following resources...
index.html
— the HTML front-end that loads all other resources
fullcalendar/*
— the JavaScript which
makes up the FullCalendar jQuery plugin and supporting CSS.
js/calendar-ajax.js
— the JavaScript code which actually does the date/event click handling,
dialogs and associated create/delete Ajax calls.
css/style.css
— styling info for page/dialogs
To setup all the resources for this problem issue the following command, from inside the p1 directory:
git clone https://github.com/bwilk7/calendar_starter_code .
How You Will Be Graded
Requirement | Points |
Total | 40 |
A GET request returns a list of calendar events | 2 |
Calendar events are returned as JSON | 5 | |
A GET request only returns dates inside the requested range | 3 |
New events are created using POST | 5 |
New events propery set the action attribute of the POST request | 2 |
A POST request for creating an new event returns the appropriate JSON (There is no parseerror) | 3 |
Each event is given a unique id | 5 |
Events are stored under the appropriate directory on GL | 5 |
Deleting an event removes it from the calendar | 5 |
A POST request for deleting an event returns the appropriate JSON (There is no parse error) | 2 |
Deleting an event deletes ONLY that event, not others on that day, etc. | 3 |
File Manager (60%)
Task
For this problem you are to implement an online file manager. Users will be able to upload files, delete files, download
files and sort based on a number of attributes.
The minimal requirements for this problem are:
- Create a script called
index.php
and place it in your p2
directory. The script should automatically
be displayed when you point a browser to: http://swe.umbc.edu/~username/cs433/web/p2/
- Upon loading the page, the user should be presented with a form that contains the following elements:
- A table which lists files that have been uploaded to the webserver.
This table should display the following for each uploaded file:
- File Name
- File Size — should be displayed in a more human readable form other than raw byte count (such as size in KB)
- File Type — do not display the actual MIME type, but rather a more human readable form (such as “PNG Image”)
- File Modification Time — this too should be in a readable format (seconds since the epoch is not acceptable)
-
There should be a link in the header of each column that allows
the user to sort on that column (1 for ascending & 1 for
descending). The name and type columns should sort
alphabetically, the size column based numerically on the number of
bytes, and the modified column should be sorted chronologically.
You must perform “custom sorting” to arrange
the files (e.g. one of the
u*sort's in PHP.
- The application should also provide the ability to upload files (up to 5 at a time) to the webserver
- It should also support functionality to remove uploaded files from the webserver
Restrictions on Files
We are going to restrict both the size and the types of files which can be uploaded for this problem. For this problem
you can assume that the maximum file size for uploads will be 50KB. Additionally, your script should limit the types of
files which can be uploaded to the following types.
Note: you must validate these types on the server-side
before keeping them. Any files larger than 50KB, or not one of
these types should be immediately removed.
Additionally, great care must be taken to scrub everything
that comes from the user. Particularly the file names
being specified by the user to view and delete a file. Your
script must only allow access to files in the sub-directory you
choose to store the files in. A user should not be able to
exploit your script by specifying a path in addition to the
file name.
Working Demo
A sample version of this application can be found at:
https://swe.umbc.edu/~bwilk1/cs433/web/p2/index.php.
You are more than welcome to utilize any of the HTML and CSS from this live example.
How You Will Be Graded
Requirement | Points |
Total | 60 |
The name of the file is displayed | 3 |
The size of a file is displayed | 2 | |
The size of a file is human readable | 2 |
The type of the file is displayed | 2 |
The type of the file is human readable | 2 |
The file time is displayed | 2 |
The file time is human readable | 2 |
The sorting of columns is correct (2 points per column-direction) | 16 |
The file name is scrubbed of all periods, slashes, and other bad characters on upload | 5 |
Uploading creates a new row in the table | 5 |
Only files of the designated types can be uploaded | 3 |
Only files under 50KB can be uploaded | 2 |
Deleting a file deletes the correct file and only the correct file | 4 |
Deleting a file takes the appropriate security precautions to not allow deletion of any random file | 4 |
HTML files are displayed correctly | 3 |
Image files are displayed correctly | 3 |
Submission
For this assignment you will not need to submit using GitHub. Rather, since the setup script
gave me the necessary permissions in your assignment directories
I will archive what I need at midnight.
After the due date you should under no circumstances edit the files
under your web
directory. When grading, the files
sitting in your directory will be diff'd against the version I archived.
Any files that were detected as changed will be treated as late and that
problem will not be graded. If you wish to continue to work on these
files, please copy them off somewhere else (under the directories created for you where it is still locked down) and work on
the copies there. Again, do not change anything under the
web
directory — doing so will result in
significant point loss.