Description
Purpose
- The purpose of this assignment is for you to apply your knowledge of server-side scripting to create a
- In this assignment, you will apply your knowledge of PHP, MySQL, Ajax, JS, Security and Regular Expressions.
EXPECTATIONS, IN DETAIL
STEP 1: Development:
- It is ideal to develop the website using your localhost setup and verify its functionality by hosting it on the FCS Bluenose server.
- You can find out more about the web hosting space assigned to you by accessing https://web.cs.dal.ca
- You are expected to develop your website to meet the acceptance criteria set out in the user stories below.
STEP 2: Your tasks:
Preliminaries:
- Clone the folder named A4 that is available on Gitlab under CSCI 2170.
- Preserve the directory structure; do not change it.
- Create new PHP and/or style/JS/image files if you need to and place these files in appropriate folders in the A4 directory that you clone/download.
- Update the README.md file with your name, B00 number, Dal email address and the Academic Integrity pledge that you submitted in Assignment 1.
- Include all citations and references to any external resource and/or code in both in the code and in README.md
- Some of the instructions require you to make certain assumptions. Any assumptions you make to implement the functionality as expected in this assignment must be described in README.md as a separate section.
User Story 1: Clean-up and use re-use principles (I know, these really should be two stories! ^_^): (10 marks)
- As a back-end web developer,
I need to use principles of re-use and clean up the code,
So that I can use best practices in programming when working on this project. - Acceptance criteria: Re-use and clean-up code in the starter assignment files:
- Move code that can be re-used, e.g. header, footer, processing, etc., into separate files where possible.
- This is the code that we worked on during a class code-along session. It is not clean, it has unnecessary elements, like the JS in index.php; see if you can clean it up.
- Fix any errors that you may encounter.
- Marking:
- The 10 marks for this user story is to ensure that you have created re-usable files and have cleaned up the code.
User Story 1 (a): Database connection and use: (5 marks)
- As a back-end web developer,
I need to connect the website to a database,
so that I can implement functionality such as storing/retrieving/modifying data in a reliable manner. - Acceptance criteria: Verify that DB.php works.
- This is mostly a verification task. Verify that db.php included in the assignment folder works on your computer.
- If it doesn’t, fix the errors.
- Create tables based on the ERD specified. You may also use the A4-tables.sql file to quickly create all tables in your MySQL or MariaDB instance.
- Note:
- When marking, we may change the DB file to work with our database on Bluenose. If you want to verify whether your file works on the FCS Bluenose server, you will need to change the DB login credentials as specified on https://web.cs.dal.ca under “Databases”. You may have to set it up on https://web.cs.dal.ca if you have not already done so.
- We will use the same table structures and same table column names. So as long as you have used the same structure referenced in the ERD and table structure diagrams without any typos or case differences, you should be okay.
- Test your code with your own data input to the DB.
- If we are unable to execute your code with our table structures, you will not receive any points for the specific functionality.
- Marking:
- The 5 marks for this task is mostly to ensure that your DB is working correctly. The DB table names and fields are provided to you, just make sure that the names used are in the correct case and exactly as specified.
User Story 2: Login and session management (And yes, you may re-use the login code you used in A3; update it as specified and just make sure that it works here too ^_^): (10 marks)
- As a user,
I need to login (and logout) from the website,
So that I can securely interact with the content on the web page. - Acceptance criteria: User submits login information (username and password):
- The website compares the username and password combination.
- Make sure that the password is encrypted before it is saved in the database.
- You can use password_hash() to generate hash of the passwords before storing them in the database.
- Encrypted passwords can be verified using password_verify().
- (4 marks — passwords are hashed and verified using these functions.)
- If the user enters the correct login information,
- The user is logged in.
- A new navigation menu link appears with a link to the list dashboard.
- A new navigation menu (a.k.a. user control) link appears with the user’s full name. This has a drop-down action that shows a link to user profile and logout.
- The user is redirected to the list dashboard after successful login.
- If the user enters the wrong login information,
- The user sees an error message below the login form, in red colour, indicating the error.
- The user is *not* logged in.
- Marking:
- (3 marks — user is logged in to access the dashboard.)
- (3 marks — user is redirected to the login page – with error – if they enter wrong login information.)
- The website compares the username and password combination.
- Acceptance criteria: User selects the logout option from the drop-down navigation:
- The user is logged out.
- The user control drop-down menu item and list dashboard menu item are removed from the navigation menu.
- (just please make sure that on logout, the behaviour is consistent with expectations in other user stories in this assignment.)
- Note:
- Set up the tables as specified in the user story named Database Connection and Use. You’ll need to use these tables for the login feature.
- Update index.php so that users see the login form if they are not logged in.
- login.php must perform the following actions:
- Process the login information and authenticate (or, verify) the user, i.e. compare the username and password submitted by the user with details stored in the DB, and verify that records match.
- The user is expected to provide their username (not email address) along with their password.
- If the user has entered wrong login information, i.e. if there is an error in either the username or password, do the following:
- Return an appropriate error code and redirect the user to the homepage. Describe the error code you will use and how you will implement it in README.md
- Clearly indicate through an error message that there has been an error. I will leave the content of the error message up to you. Ensure that this error message is in a colour that is different from the regular text so that it is emphasized. This feedback to the user also ensures that you have implemented “Visibility of System Status”, which is one of the important Usability Heuristics.
- If the user enters the correct information:
- Store user details such as full name, username and user type as session variables, since they may be needed for other features.
- Implement the logout feature in logout.php stored in the includes folder.
- This file must log the user out by destroying the session appropriately. There is one standard way of doing this as discussed in class. Please use it and cite it appropriately.
Ajax expectations for User Stories 4, 5 and 6
- Use Ajax for managing actions in the dashboard (e.g. marking a list as done [archived] or not done [unarchived], quick edit, etc.)
- Use Ajax to add list item to the list (when creating and editing the list).
- Feel free to use Ajax for other functionalities, where applicable.
User Story 4: User is on the list dashboard page: (25 marks)
- As a user,
I need to be able to see a dashboard of my lists,
So that I can see all lists and manage them or create a new list. - Acceptance criteria: User lands on the list dashboard page.
- If the user is logged in:
- User sees all lists that they have created, or an indication that they have not created any lists.
- (5 marks — the focus here is to see the lists or not, and a notice if there are no lists.)
- The user sees their full name in the navigation menu, with a drop-down option to logout appearing when they click on the name.
- (3 marks)
- The user sees a link to the list dashboard in the navigation menu.
- (2 marks)
- The user sees all lists that they have created in the dashboard page.
- (5 marks — the focus here is on the lists, if they are created, users should see all lists they create.)
- If the user has not created any lists, a simple message to indicate that there are no lists to display will be shown to the user.
- (Marking guideline is covered in the first item in this acceptance criteria.)
- The user sees an option to create a new list.
- (5 marks — a clear option to create a new list, not hidden under some menu. Clear and visible with an identifiable call-to-action.)
- For each list that the user has created, the user sees options to — (a) edit the list, (b) archive or mark as done (changes to mark as not done when clicked), (c) delete the list.
- (3 marks — associated with each list must be the options to edit/archive/delete, with corresponding actions listed in User Story 6.)
- User sees all lists that they have created, or an indication that they have not created any lists.
- If the user is not logged in:
- The user does not get to view the list dashboard page. They are redirected to the login page (homepage) saying that all features of the site require people to login.
- (3 marks — secure access to the dashboard.)
- The user does not get to view the list dashboard page. They are redirected to the login page (homepage) saying that all features of the site require people to login.
- If the user is logged in:
User Story 5: User creates a new list: (25 marks)
- As a user,
I need to be able to create a new list,
So that I can plan things to do in my daily schedule. - Acceptance criteria: User clicks on the option to create new list in the list dashboard.
- User is taken to the create a list page, which is an updated version of the list interface that is given to you through Gitlab.
- (4 marks — user is able to see that the create list interface is behind the login-wall, i.e. has secure access. Not everyone can access the create a list page, only those who are logged in.)
- (3 marks — the interface to create a list has a consistent user interface appearance as other parts/pages of the website.)
- User is able to give a name to the list.
- If user does not provide a name, the default name is “My List #“, where # is replaced by the value of list_id in the alllists table.
- (3 marks — user is able to save a name to the list.)
- (3 marks — the default name of the list is as specified above.)
- All other functions of creating the list are retained from the code given to you.
- (2 marks)
- If user clicks on the option to save the list, user is redirected to the list dashboard and they see their new list in the dashboard.
- (2 marks — for redirection.)
- (4 marks — list shows up in dashboard.)
- User also has an option to discard the list, at which point the list entries and the list are deleted and user is redirected to the dashboard.
- (1 mark — for redirection.)
- (3 marks — database entries are properly discarded.)
- User is taken to the create a list page, which is an updated version of the list interface that is given to you through Gitlab.
User Story 6: User manages their lists: (40 marks)
- As a user,
I need to be able to manage my lists,
So that I can edit, delete or archive my lists. - Acceptance criteria: User chooses to edit a list.
- User is taken to an “update list” interface, which looks exactly like the “create a new list” interface.
- Only this time, all the items from the list being edited are displayed in the fields.
- (3 marks — look and feel is like the “create a new list” interface.)
- (4 marks — data is displayed in the fields.)
- User is able to mark items as done (or as not done), delete items and add items to the list.
- This is based on what we have already done in class and what you have in the code given to you through Gitlab.
- (3 marks)
- User sees a save changes button.
- (2 marks — the presence of the save button.)
- (3 marks — clicking on the save button saves all changes made to the list.)
- User is taken to an “update list” interface, which looks exactly like the “create a new list” interface.
- Acceptance criteria: User chooses to save the edited list.
- User is redirected to the dashboard.
- (2 marks — after saving all changes as explained above, user is redirected to the dashboard.)
- User is redirected to the dashboard.
- Acceptance criteria: User chooses to delete the list.
- User’s list is deleted.
- In the DB, each list (alllists table) is associated with many list items (mylist table).
- All list items associated with the list must be deleted from the mylist table when a list is deleted. One SQL query for this, please.
- (7 marks — all items in the both tables are appropriately deleted.)
- The dashboard view is refreshed after the delete action is completed.
- (3 marks — dashboard view is refreshed.)
- User does not see the deleted list when the dashboard view updates.
- (3 marks — deleted list is removed from the view.)
- User’s list is deleted.
- Acceptance criteria: User chooses to archive a list (or mark a list as done).
- User sees a way to know that the list is archived (or marked as done).
- This could be either through (a) changing the appearance of the list title, (b) moving the list to another part of the dashboard view. I leave this choice to you.
- (5 marks — user clearly knows whether the list is archived. There is clear distinction between active lists and archived lists.)
- User sees a way to unarchive the list (or mark as not done).
- This could be through a button or option that is visible below the list’s name, just like what we have now for individual list items.
- If the list is marked as unarchived or not done, the list’s appearance should go back to the default view, i.e. changes to appearance or position made under the above acceptance criteria must be reverted to default.
- (5 marks — the action link or button is clear and unambiguous.)
- User sees a way to know that the list is archived (or marked as done).
- Bonus Acceptance Criteria (10 marks): User is able to quick edit the list.
- User sees an option to “quick edit” the list.
- When user clicks on quick edit, user must:
- Be able to edit only the title of the list without leaving the dashboard.
- A small form text input must become visible below the title of the list with the current title visible.
- User must see options to save changes and cancel.
- If user clicks on save changes the title must be updated.
- If user clicks on cancel the title must not be updated.
User Story 7: Controlling what data users input (15 marks)
- As a user,
I need to submit only valid characters to the list,
So that I can ensure that the list is secure. - Acceptance criteria: User enters list items:
- Data entered is verified using regular data sanitization techniques to validate data being input to the database.
- (5 marks)
- The MySQLi method $mysqli_connection_object->real_escape_string(escapestring) is used to escape strings before input to the database.
- (5 marks)
- Data entered is verified using regular data sanitization techniques to validate data being input to the database.
- Acceptance criteria: User enters list names:
- User is not allowed to enter any special characters in list names.
- User regular expressions to validate data being input.
- (5 marks — validate names to avoid special characters from being submitted to the table.)
- Data entered is verified using regular data sanitization techniques to validate data being input to the database.
- (Marking covered under the first acceptance criteria above.)
- The MySQLi method $mysqli_connection_object->real_escape_string(escapestring) is used to escape strings before input to the database.
- (Marking covered under the first acceptance criteria above.)
- User is not allowed to enter any special characters in list names.
User Story 8: Role-based access control (20 marks)
- As an administrator,
I need to see user information,
So that I can view a list of all users and their email addresses. - Acceptance criteria: Navigation menu:
- When the administrator is logged in (user type 0 in the users table), they must see a new item named View all users in the navigation menu.
- (4 marks — administrator is able to see all users who are registered in the system, including themselves.)
- Other users must not see this menu item.
- (4 marks — role-based access — no other type of user is able to see all users, even if they try to access the page by manually entering the URL.)
- (2 marks — role-based access — if a user other than administrator tries to access this page to view all users, they are redirected to the dashboard.)
- When the administrator is logged in (user type 0 in the users table), they must see a new item named View all users in the navigation menu.
- Acceptance criteria: Administrator clicks on View all users from the navigation menu:
- User is taken to a new page (view_users.php) that has the same appearance as other pages.
- (3 marks — only administrators are taken to this new page.)
- (2 marks — this page has an appearance and look-and-feel consistent with other pages on this website.)
- The administrator sees an HTML table with a list of all users (their full names and email addresses only).
- (5 marks — administrator sees a list of all users registered on the site in a table.
- Just placing a table and content in the table gets you a maximum of 75%, i.e. 3.5/5.
- For getting 100% in this aspect, you will need to go above and beyond just placing a table — style the table appropriately using CSS, use a colour scheme consistent with the web page that you have used, etc.)
- (5 marks — administrator sees a list of all users registered on the site in a table.
- User is taken to a new page (view_users.php) that has the same appearance as other pages.
User Story 9: User profile (50 marks)
- As an user or administrator,
I need to see my profile,
So that I can view my information and edit email addresses or first/last names. - Acceptance criteria: Navigation menu:
- When the user or administrator clicks on the user profile link from the user control drop-down in the navigation menu, they are redirected to a page named profile.php
- (3 marks — user is redirected appropriately.)
- (3 marks — access control — only logged in users have access to this page. If users try to access this page without logging in and by typing in the URL, they are redirected to the homepage.)
- When the user or administrator clicks on the user profile link from the user control drop-down in the navigation menu, they are redirected to a page named profile.php
- Acceptance criteria: User or administrator clicks on the user profile link from the user control drop-down:
- User is taken to a new page (profile.php) that has the same appearance as other pages.
- The profile page shows:
- The user’s (or administrator’s) full name (first and last).
- The user’s email address.
- The user’s username.
- The user’s password
- (hidden using *, use password input field)
- The user’s phone number.
- A default profile image (defaultprofile.png that is available in the img folder) – no option to change this image.
- (4 marks — all information is shown as specified.)
- The profile page allows user or administrator to edit:
- Email address
- Phone number
- First and last names
- Password
- (3 marks — only the above information is editable.)
- Hints / suggestions:
- Try to structure the page like a form with disabled input text fields that are pre-filled with data from the table.
- When the user clicks on edit, enable all fields and update the tables when they click on save.
- Acceptance criteria: User or administrator wants to update information in the profile:
- User clicks on edit profile to see all editable fields enabled (only the ones listed above).
- (3 marks — the call-to-action to edit the profile is clearly visible to users.)
- User is able to modify the field.
- If user enters a new password, it must be hashed and stored in the database.
- (4 marks — password hashing.)
- (2 marks — password storage in the DB.)
- If user enters a new email address, it must be a valid email address — use regular expressions to verify.
- (6 marks — valid email address entered and verified using regex.)
- If user enters a new phone number, it must be in the format (###)-(###)-(####) — use regular expressions to verify (a) that there are 10 digits in the number, and (b) that the numbers are organized in that format.
- (4 marks — regex verification to count number of digits in the phone number.)
- (4 marks — regex verification to verify if number organized in that format.)
- After editing the fields, user can either save profile or cancel changes.
- (2 marks — the two options are clearly visible.)
- User clicks on edit profile to see all editable fields enabled (only the ones listed above).
- Acceptance criteria: User or administrator clicks on save profile:
- All changes are saved in the database.
- (2 marks)
- The profile page reloads and the changes are visible.
- (3 marks)
- All form fields are disabled again, but with data visible.
- (3 marks)
- All changes are saved in the database.
- Acceptance criteria: User or administrator clicks on cancel changes:
- Changes are discarded and the page is reloaded to show original data (without modification or edits).
- (4 marks)
- Changes are discarded and the page is reloaded to show original data (without modification or edits).
Citations:
- Citations must be in the ACM format that is described on the official ACM web page here:https://www.acm.org/publications/authors/reference-formatting
- Citations must be included in README.md and in the code if you have used any external resources to learn about specific code segments.
STEP 4: What do I submit?
- You are required to submit this assignment in two places — (a) Brightspace, and (b) Gitlab.
- Submission on Gitlab —
- Instructions to submit assignments on Gitlab (https://git.cs.dal.ca/) have been posted in a section under “Content >> Assignments” — if you have any questions, please reach out to the CS Help Desk.
- Submission on Brightspace — A single zip file named <LASTNAME>_<FIRSTNAME>_B00XXXXXX_A4A5.zip
- Replace <LASTNAME> with your last name, and <FIRSTNAME> with your first name.
- Replace “B00XXXXXX” with your B00 number.
- The above ZIP file should preserve the directory structure available in Gitlab. You may add additional PHP and/or other files as needed. Include a summary of the files you have added and why in README.md
STEP 5: Marking Scheme
- Detailed marking scheme is available — as part of the user story and acceptance criteria — no separate document.
